Single Sign-on in der Cloud

Die Magie hinter Single Sign-on (SSO) in Active-Directory-Netzwerken liegt in den Protokollen, mit denen das Active Directory (AD), Computer und Anwendungen sowie Dienste kommunizieren: Kerberos und das veraltete NTLM. Sprechen alle Teilnehmer dieselbe Sprache, kann die Anmeldung am Computer gegen das AD dazu dienen, um untereinander Tickets auszutauschen, die für die Anmeldung an alle verbundenen Apps und Dienste gelten. Microsoft stellt sich vor, dass diese Funktion für alle Cloudanwendungen nun dem Azure Active Directory (AAD) zugeht. Das lokale AD ist dafür ungeeignet, weil es Protokolle spricht, die für den lokalen Einsatz optimiert sind. Azure AD hingegen, als natives Kind der Cloud, spricht seit Geburt moderne Protokolle wie SAML und OpenIDConnect, die als Industriestandards schon länger in bekannten SaaS-Anwendungen arbeiten.

Es gilt, ein ähnliches Setup zu erreichen wie im AD: Verstehen möglichst viele Apps, Computer und Benutzer dieselben Protokolle und befinden sich in einem gemeinsamen Verbund, können Tokens ausgestellt werden, die umfassendes Vertrauen genießen – womit nicht jeder Dienst erneut nach einem Passwort fragen muss. Diese Tokens kommen in der Microsoft-Cloud vom AAD und per Integration von SaaS-Anwendungen und Apps vertrauen diese Apps diesen Tokens. Wie aber erfolgt ein SSO nach AAD, um dann weiter zu den verbundenen Apps zu kommen?

Drei Optionen für Cloud-SSO

Um den Sprung von Windows AD nach Azure AD per SSO ohne neue Passworteingabe zu vollziehen, sind drei Methoden möglich, denn im Bestfall behalten wir nur die PC-Anmeldung als einzige Anmeldung für Windows-AD und AAD bei: entweder betreiben Sie einen Anmeldedienst, der aus dem Login am PC eine gültige Webanwendung macht – also einen Identity Provider, der aus Kerberos moderne Protokolle generiert. Oder Sie synchronisieren tausendfach berechnete Hashes aus den Windows-AD-Passworten, damit

Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.