Kolumne: Stropek as a Service

Identity Management als Herausforderung in SaaS-Anwendungen
Keine Kommentare

Kaum ein Team, das in Richtung SaaS startet, schätzt die Komplexität des Themas Identity Management richtig ein. In dieser Ausgabe der Kolumne werden typische Fehler beim Umgang mit Identity Management aufgezeigt und wie man diese mit möglichen Gegenmaßnahmen verhindern kann.

Wenn ich SaaS- und Cloud-Transformationsprojekte mit Kunden starte, steht ein Thema immer auf der Tagesordnung: Identity Management (IdM). Kaum ein Team, das in Richtung SaaS startet, schätzt die Komplexität dieses Themas richtig ein. Die meisten meinen, es wäre eine Kleinigkeit, die im Vorbeigehen mit erledigt wird. Nach kurzer Zeit merkt man aber, dass IdM ein sprichwörtliches Rabbit Hole ist, in dem man sich sowohl funktional als auch technisch verlieren kann. In dieser Ausgabe meiner Kolumne möchte ich auf einige typische Fehler eingehen, die ich in Praxisprojekten in Sachen IdM regelmäßig erlebe, und mögliche Gegenmaßnahmen vorschlagen.

IdM als Teil eines Pilotprojekts

Wenn eine Firma neu in das SaaS-Geschäft einsteigt, geschieht das meistens im Rahmen eines Pilotprojekts. Es wird ein digitaler Service ausgewählt, den man als SaaS-Angebot vermarkten möchte und mit dem die Entwicklung gestartet wird. Mittel- bis langfristig sollen dann weitere digitale Dienste dazukommen. In einem solchen Umfeld ist es nach meiner Erfahrung ein Fehler, wenn IdM organisatorisch und budgetär dem Pilotprojekt zugeordnet wird. Eine IdM-Strategie festzulegen und umzusetzen, ist in jeder größeren Organisation zeitaufwendig und teuer. Wenn man nicht aufpasst, baut das Team des Pilotprojekts verständlicherweise eine auf die Mindestanforderung des konkreten Projekts zugeschnittene Minimallösung, um Entwicklungszeit und -kosten im Rahmen zu halten. Diese Strategie ist aus Sicht des Projekts zielführend. Für eine längerfristige SaaS-Strategie, die eine Vielzahl an Teilprodukten und Teams abdecken muss, ist das erstellte IdM-System aber keine tragfähige Lösung.

IdM sollte als eigenes Projekt mit einem eigenen Team vorangetrieben werden. Es handelt sich um einen (Micro-)Service, der von den anderen SaaS-Teams in Anspruch genommen werden kann. Es braucht eine eigene Roadmap, fest zugeordnete Ressourcen, ein eigenes Projektbudget etc.

Zu viel Eigenbau

Teams ohne SaaS-Erfahrung schrecken vor der Komplexität von sicherheitsbezogenen Protokollen wie OpenID Connect zurück oder fühlen sich von der Fülle an fertigen Komponenten und Services für Authentifizierung erschlagen. Sie sagen, ihre Lösung sei nicht so komplex. Sie wollen klein und einfach starten. Ein bisschen Benutzer- und Passwortverwaltung, eine Log-in-Maske – so schwer kann Authentifizierung doch nicht sein, oder? Ich bin ein großer Freund davon, Overengineering zu vermeiden. IdM von Grund auf selbst zu bauen wäre aber in den meisten Projekten das Gegenteil, nämlich Oversimplification. Bei einer SaaS-Lösung, die im öffentlichen Internet läuft, ist professionelles IdM unverzichtbar. Protokolle und deren Implementierungen müssen solide sein, und daher sollte man auf geprüfte und verbreitete Standards, Bibliotheken und Services setzen, wenn man nicht selbst IdM-Anbieter werden möchte.

Leichtfertige Strategiewechsel

„Wir starten mal mit dem Ansatz X und wenn nötig, wechseln wir später.“ Diesen Satz habe ich schon oft von Teams in Bezug auf IdM gehört und die Betroffenen haben diese Strategie so gut wie immer bereut. Den grundlegenden Ansatz von IdM in einem laufenden, produktiven SaaS-System zu ändern, ist ein riskantes Monsterprojekt. Eine reibungslose User Experience bei einer fundamentalen Umstellung im Bereich IdM sicherzustellen, ist sehr aufwendig, oft unmöglich. Fehler können fatal sein, da sie leicht zu schwerwiegenden Sicherheitslücken führen. Ein Ausfall ist schwerwiegend, da ohne Authentifizierung die Benutzer von der SaaS-Lösung ausgesperrt werden.

Agile Methoden haben ihre Vorteile. Wenn es um IdM geht, ist aber eine sorgfältige Planung der Anforderungen und der Umsetzung unvermeidbar. Man sollte sich bemühen, es von Anfang an halbwegs richtig zu machen und eine Lösung zu bauen, die die Anforderungen längerfristig erfüllen kann.

Lock-in-Effekt vermeiden

Vendor-Lock-in-Effekte sind in jedem Cloud-basierenden SaaS-Projekt ein Thema. Natürlich möchte man nicht mit Haut und Haar einem Cloud-Anbieter ausgeliefert sein. Teams legen daher Wert auf portable Lösungen. Gerade im Bereich IdM kann das zum Problem werden, wenn der Wunsch nach Unabhängigkeit von Cloud-Anbietern nicht zu den vorhandenen Ressourcen für Planung und Umsetzung passt. Wer ein eigenes professionelles IdM-System zum Beispiel auf Basis von Open-Source-Bibliotheken wie IdentityServer aufbauen will, muss bereit sein, entsprechend zu investieren. Zu berücksichtigen sind Dinge wie Ausbildung, initiale Entwicklung, Automatisierung von DevOps-Prozessen, regelmäßige Wartung inklusive entsprechender Prozesse für dringende Aktualisierungen bei plötzlichem Bekanntwerden kritischer Sicherheitslücken etc. Wer seine Aufmerksamkeit und sein Geld lieber in inhaltliche Programmfunktionen investiert, der ist – trotz Vendor Lock-in –bei fertigen Identity-as-a-Service-(IDaaS-)Diensten wie AAD B2C, Auth0, Okta und Co. besser aufgehoben.

Wer rasch einen Überblick über die weltweit führenden IDaaS-Anbieter möchte, kann einen Blick in den entsprechende Gartner Magic Quadrant werfen [1]. Aber Achtung: Gartner beurteilt die Gesamtstrategie der Anbieter. Microsoft wird beispielsweise mit all seinen AAD-bezogenen Angeboten in einen Topf geworfen. Lösungen wie Auth0, die sich aus meiner – zugegeben entwicklungslastigen – Perspektive sehr gut für Cloud-basierte SaaS-Lösungen eignen, werden mit Produkten verglichen, deren historischer Schwerpunkt auf der On-Premises-Installation liegt. Insofern sollte der Magic Quadrant nur als Startpunkt für die Suche nach der passenden Lösung verwendet werden und man muss sich die Zeit nehmen, die Anmerkungen zu lesen und sie mit den eigenen Anforderungen in Bezug zu setzen.

Missverständnis bezüglich AAD

Microsoft bewirbt Azure Active Directory (AAD) mit dem Slogan „Interagieren mit Benutzern und Partnern – schützen und verwalten Sie Kunden und Partner über die Grenzen Ihrer Organisation hinaus“ [2]. Das scheint auf den ersten Blick bestechend. Scheinbar kann ein SaaS-Hersteller AAD sowohl für interne als auch für externe Personen verwenden. Das klingt gut, da jede Organisation bestrebt ist, vorhandenes Wissen wiederzuverwenden.

Die Marketingbotschaft von Microsoft ist nicht falsch, im Gegenteil. AAD ist gut dafür geeignet, externe Personen wie freiberufliche Mitarbeiterinnen, Leasingpersonal oder Personen von wichtigen Lieferanten und Partnern zu verwalten, um beispielsweise mit Hilfe von Office 365 mit ihnen zusammenzuarbeiten. Die Lösung passt nur leider nicht sonderlich gut für SaaS-Angebote [3].

AAD hat auch etwas für SaaS im Angebot. Erstens gibt es die sogenannten Multi-Tenant Applications [4]. Dieser Ansatz passt gut, wenn man eine B2B-SaaS-Lösung erstellt und viele der SaaS-Kunden selbst ein AAD, zum Beispiel wegen Office 365, haben. Als SaaS-Anbieter kann man dem Kunden Single Sign-on (SSO) anbieten, indem sich sein Personal über das kundeneigene AAD beim SaaS-Produkt anmeldet. Zu beachten ist dabei, dass die IdM-Lösung bei diesem Ansatz dem Endkunden gehört und von ihm verwaltet wird. Microsoft hat in den letzten Jahren mit Office 365 einen beeindruckenden Marktanteil erreicht. Insofern ist die Unterstützung von SSO mit AAD ein Muss für so gut wie jede moderne B2B-SaaS-Lösung.

Die zweite AAD-Lösung, die Microsoft für SaaS-Anwendungen vorsieht, ist Apps for Consumers or Customers, besser bekannt unter der Abkürzung AAD B2C. Sie ist einen eigenen Abschnitt wert.

Azure Active Directory B2C

AAD B2C ist eine beeindruckende IdM-Lösung. Sie verkraftet ohne Weiteres Millionen Benutzerkonten und ist bis 50 000 Benutzer kostenlos. Die meisten B2C-SaaS-Lösungen, mit denen ich zu tun habe, können von einer solchen Benutzerzahl nur träumen. Ist AAD B2C daher die perfekte Lösung für IdM bei SaaS-Anbietern mit gutem Verhältnis zu Microsoft? Das stimmt leider nur bedingt. Wenn das primäre IDaaS-Auswahlkriterium die Skalierbarkeit ist, liegt AAD B2C sicher gut im Rennen. Wenn es aber um Funktionalitäten und Produktivität der Entwicklungsteams bei IdM-bezogenen Aufgaben geht, hat AAD B2C das Nachsehen gegenüber entwicklungsfreundlichen IDaaS-Diensten wie Auth0.

Wer billig kauf, kauft manchmal teuer

Natürlich spielen die Kosten einer IdM-Lösung eine Rolle. Es gibt eine Vielzahl von Kosteneinflussfaktoren: initiale Entwicklungskosten, Personalaufwand für laufende Wartung, monatliche Kosten der IDaaS-Plattform, monatliche Cloud-Betriebskosten einer eigenen IdM-Lösung, produktspezifische Ausbildungskosten etc. Ich habe in vielen Projekten die Tendenz dazu festgestellt, sich bei der Auswahl zu sehr auf die leicht zu beziffernden Faktoren zu beschränken. Die monatlichen Kosten von IDaaS sind ein gutes Beispiel. Sie können auf einfache Weise ermittelt werden. Wer den leichten Weg geht und den IDaaS-Anbieter mit den niedrigsten monatlichen Kosten nimmt, der zahlt vielleicht am Ende drauf. AAD B2C ist ein gutes Beispiel. Die Lösung ist sehr kosteneffizient in kleinen bis mittelgroßen SaaS-Projekten. Sie ist jedoch funktional gegenüber anderen Ansätzen wie einer selbstentwickelten IdentityServer-basierten Lösung oder gegenüber Auth0 stark eingeschränkt (z. B. UI-Anpassungsmöglichkeiten, unterstützte Log-in-Flow-Typen). Eventuell fehlende Funktionen in Nachhinein „dazuzubasteln“, ist fehleranfällig, teuer und manchmal sogar überhaupt nicht mit wirtschaftlich sinnvollem Aufwand machbar.

Funktionale Anforderungen nicht geklärt

Ich möchte mit dem am schwierigsten zu vermeidendem Fehler schließen: IdM-Lösungen werden oft von Technikerinnen und Technikern ausgewählt, da es sich um eine technisch komplexe Materie handelt. Tatsächlich beeinflusst das IdM aber stark die User Experience des Gesamtsystems. Der Registrierprozess ist der erste Eindruck, den die Benutzer eines SaaS-Systems von der Lösung bekommen. Sie müssen sich jeden Tag implizit oder explizit auf unterschiedlichsten Geräten (z. B. PC, Smartphone, IoT-Gerät) authentifizieren. Administratorinnen brauchen eine übersichtliche Lösung, die Fehlkonfigurationen vermeidet, da eine solche zu Sicherheitslücken oder einer Behinderung der Endbenutzer führen würden.

Für die Gestaltung einer passenden IdM-Strategie braucht es eine enge Zusammenarbeit von Personen aus der Softwareentwicklung, aus dem Bereich IT-Sicherheit und dem Produktmanagement (inklusive User-Experience-Design). Nur eine Betrachtung all dieser Aspekte führt zu einer fundierten Auswahl, die langfristig Bestand haben wird.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Abonnieren
Benachrichtige mich bei
guest
0 Comments
Inline Feedbacks
View all comments
X
- Gib Deinen Standort ein -
- or -