© Burmakin Andrey, 123RF

Gerade in einer Cloud muss sichergestellt sein, dass ihre Benutzer nur auf die für sie bestimmten Anwendungen und Daten zugreifen dürfen. Wie eine zentrale Instanz diesen Zugang per Open ID und SAML einfach regeln kann, das diskutiert dieser Beitrag.

Zentrales Benutzermanagement soll sicherstellen, dass sich Benutzer mit einem Passwort (oder besser: ganz ohne) von verschiedenen Orten und mit diversen Endgeräten bei unterschiedlichen Diensten anmelden können. Sie sollen die Rechte erhalten, die ihrer Position und ihren Aufgaben entsprechen. Verlassen sie die Firma, soll der Zugang erlöschen. Regeln soll das alles ein modulares System, das auch den Ausfall einzelner Komponenten übersteht.

Solange es sich nur um eine einzelne Anwendung dreht, mag es vertretbar sein, die Benutzer in dieser Anwendung zu verwalten. Aber in einer Cloud, in der schnell weitere Anwendungen hinzukommen, ist eine zentrale Benutzerverwaltung, unabhängig von einer bestimmten Applikation, ein Muss. Dann ist auch eine Integration neuer Anwendungen in dieses Usermanagement leicht.

Allerdings entstehen damit auch neue Abhängigkeiten. Denn fällt das Nutzermanagement infolge eines lokalen Problems aus, könnten zum Beispiel auch Remote-Arbeitsplätze betroffen sein. Ein dedizierter Server für das Identity and Access Management (IAM) in der Cloud hilft, diese Gefahr zu reduzieren.

Die Cloud garantiert hier gleichzeitig die Skalierbarkeit der Lösung: Steigt später die Zahl der Benutzer und Anwendungen, kann der Admin die Kapazitäten aufstocken. Oder er beschäftigt während der Bürozeiten zwei IAM-Server und schaltet nachts einen von ihnen wieder ab.

Offen oder geschlossen?

Hat sich der Admin für ein IAM in der Cloud entschieden, stellt sich ihm die Frage, ob er eine offene Lösung oder ein geschlossenes System einführen soll. Außerdem muss er sich für oder gegen eine Software-as-a-Service-Lösung (SaaS) entscheiden. Setzt der Admin auf SaaS, hat er in der Regel keine Kontrolle über das IAM-System als solches, weil er nur Zugriff über APIs und ein Managementinterface hat.

Ein offenes System bietet dagegen einige Vorteile. Am wichtigsten ist, dass man selbst die volle Kontrolle über die Daten und Metadaten behält. Die umfassen dabei solche Informationen wie: Wann melden sich Benutzer welcher Plattform von wo an? Oder: Wie oft ändern sich Benutzerdaten?

Auch bei der Auswahl von Anwendungen hat eine offene Lösung Vorteile. Wer Zugriff auf das System selbst und die Rohdaten hat, kann einfach weitere Anwendungen anbinden. Bei geschlossenen Lösungen ist man hingegen auf das Wohlwollen des Anbieters angewiesen. Entscheidet der, dass eine bestimmte Anbindung für ihn nicht mehr wirtschaftlich ist, kann er sie einfach abschalten.

Der Einsatz von IAM-Systemen als Open Source macht auch die Entwicklung von Erweiterungen möglich, über die sich spezielle Anwendungen koppeln lassen. Und schließlich ist auch der Wechsel zwischen zwei Anbietern bei geschlossenen Systemen oft schwer oder gar nicht möglich. Bei offenen Systemen hingegen ist der Aufwand deutlich geringer.

Letztlich ist es auch eine Frage von Transparenz und Kontrolle. Bei einer Open-Source-Lösung kann der Administrator steuern, was mit den Daten passiert. Er kann sich so zum Beispiel sicher sein, dass kein Dritter die Daten ohne sein Wissen weiterverkauft.

Kerberos und LDAP

Kerberos und LDAP sind seit fast 20 Jahren der Standard für die Authentifizierung von Benutzern und das Management von Accounts. Beide sind bereits auf eine Nutzung über unsichere Netze ausgelegt. Auch erlaubt Kerberos Single Sign-on, sodass der Nutzer sich nur zu Beginn der Session authentifizieren muss.

Doch gibt es auch deutliche Nachteile von Kerberos und LDAP. Der größte Nachteil ist die Zahl der Ports und Protokolle, die Kerberos braucht, um zu funktionieren. Die müssen in der Firewall freigegeben und gleichzeitig auch überwacht werden. Auch stellen die Synchronisation der Uhrzeit und die Nutzung des DNS eine Hürde dar.

Kerberos hat hier jeweils hohe Anforderungen. Beispielsweise dürfen die Uhren von Client und Server nur fünf Minuten voneinander abweichen. Mit der Provisionierung per LDAP gibt es zusätzlich das Problem, dass die beiden meist genutzten LDAP-Implementierungen, Open LDAP und Microsoft Active Directory, sich erheblich unterscheiden. .

Authentifizierung in Clouds

Aus den Ideen, die in die Entwicklung von Kerberos eingeflossen sind, haben sich einige Protokolle entwickelt, die ähnliche Sicherheit bieten, jedoch HTTP-Verbindungen und Browser-Cookies für die Authentifizierung nutzen. Die bekanntesten Protokolle sind die Security Assertion Markup Language (SAML, [1]) und Open ID [2].

Bei Open ID hat jeder Benutzer eine eindeutigen URL, um sich zu authentifizieren, Beispiel: »korte.OpenID.univention.de«. Der Domänenteil (»OpenID.univention.de«) weist dabei den Aussteller aus, bei dem die Authentifizierung erfolgen soll. Da Domänen eindeutig sind, ergibt sich zusammen mit dem Namen – hier »korte« – eine eindeutige Identität.

SAML setzt Vertrauen zwischen Dienst und Benutzerverwaltung voraus, wofür der Admin sorgen muss. Wie die Zuordnung zwischen Nutzer und Nutzermanagement erfolgt, bleibt dabei dem einzelnen Dienst überlassen, wobei viele Dienstanbieter hier auf die E-Mail-Adresse setzen, um eine eindeutige Kombination aus Domain und Nutzernamen zu erhalten.

In beiden Fällen ist die Anmeldung sehr ähnlich. Auf der Webseite des Dienstanbieters gibt der Nutzer seinen Nutzernamen, E-Mail-Adresse oder URL ein und der Dienst leitet ihn weiter zum IAM. Das fragt das Passwort ab und vergibt einen Cookie zum Nachweis der erfolgreichen Authentifizierung. Mit diesem Cookie geht der Nutzer dann zurück zum Dienst und schließt die Anmeldung ab.

Die eigentliche Authentifizierung – egal ob über Hardware-Token, Zwei-Faktor-Authentifizierung oder Passwort – erfolgt dabei ausschließlich auf dem Nutzermanagementsystem. Die Authentifizierungsdaten verlassen niemals den Kontrollbereich des IAM.

Open ID Connect

Die Identifizierung und Authentifizierung von Benutzern ist aber nur ein Teil der Anforderungen an ein IAM. Wesentlich wichtiger ist das Management der Benutzer und seiner Attribute. So gilt es, die richtigen Benutzerdaten an die richtigen Dienste zu übermitteln. Außerdem gehört es zur Benutzerverwaltung, ausgeschiedene Benutzer zu löschen.

Viele Dienste bieten hier nur ein selbst entwickeltes API an, mit dem sich Benutzer verwalten lassen. Es unterscheidet sich dann vom API aller anderen Dienste. Daher ist es oft nötig, dass das Benutzermanagement einen Connector zu den entsprechend APIs mitbringt.

Für einige Zeit schien es so, als würde Open ID Connect dieses Problem überwinden und ein standardisiertes API bereitstellen, das es Benutzern erlaubt, die Attribute ihrer Identität mit dem Dienst zu teilen. Dabei ermöglicht es Open ID Connect sogar, verschiedenen Diensten unterschiedliche Attribute mitzugeben. Derzeit gibt es mehrere Ansätze, etwa ID4ME [3] von Denic [4], die die Nutzung von Open ID Connect [5] als ein offenes Protokoll fördern wollen. Bisher ist aber noch nicht abzusehen, wann diese Bemühungen zum Erfolg führen.

Der Weg zu einem Cloud-IDM kann über komplizierte Konfigurationen führen, im günstigsten Fall aber auch über fertig konfigurierte Open-Source-Lösungen. Was am besten ist, hängt stark von den Anforderungen ab. Viele Softwarekomponenten, etwa Simple SAML PHP [6], Open AM [7] und CAS [8], sind als Open-Source-Software verfügbar und lassen sich individuell installieren. Dabei spielt es keine Rolle, ob die Komponenten auf einem eigenen Server laufen oder der Admin sich für eine Cloudinfrastruktur wie AWS entscheidet.

Die einzelnen Komponenten sind an die eigenen Bedürfnisse anpassbar, der Anwender muss nur installieren, was er wirklich braucht. Allerdings sollte er nicht unterschätzen, wie viel Know-how er für das Aufsetzen der Lösung und die laufende Wartung benötigt.

Den Mittelweg bilden Docker-Images [9] oder komplette Konfigurationen aus Docker-Containern, die die nötigen Komponenten bereitstellen und die Orchestrierung übernehmen. Noch einfacher machen es schließlich fertige Images und Software-Komplettlösungen wie der Univention Corporate Server [10].

Zusammenfassung

Die einfache zentrale Verwaltung von Benutzern in einer Cloud ist ein nicht zu unterschätzender Vorteil. Dabei spielt es keine Rolle, wie viele Benutzer im Unternehmen sind. Der Administrator hat alles in einem System und behält die Kontrolle. Genauso wichtig ist aber auch, dass ein zentrales Nutzermanagement Single Sign-on für die Benutzer ermöglicht. Der Komfortgewinn kann maßgeblich dazu beitragen, dass Nutzer nicht in die Schatten-IT ausweichen.

Mit einem offenen System lässt sich eine solche Benutzerverwaltung nicht nur schnell und einfach, sondern auch transparent und sicher realisieren.