Ich beginne mit der Feststellung, dass die heutigen Identitätstechnologien sehr verwirrend sein können. Es gibt viele Dienste (im Zeitalter der Cloud ist alles ein Dienst), Protokolle, Lösungen, SDKs, Technologien und Produkte, die das Identitätsproblem lösen sollen.

Ich beginne mit einem Vergleich der beiden grundlegenden Dienste, die vielleicht am verwirrendsten sind, da sie zufällig denselben Namen tragen: Die guten alten Active Directory Domain Services (kurz ADDS) und Windows Azure Active Directory (kurz AAD).

ADDS wird seit Ewigkeiten verwendet (nun, 13 Jahre in Computern erscheinen wie Ewigkeiten), um Authentifizierungs- und Autorisierungsdienste (AuthN und AuthZ) innerhalb des Unternehmensrechenzentrums (der lokalen Umgebung) bereitzustellen. Es ist ziemlich populär (87% der Fortune 1000 nutzen es laut Gartner) und hat sich bei der Bereitstellung aller erforderlichen Dienste als ziemlich solide erwiesen. (Haftungsausschluss: Ich habe es früher bei MSFT unterstützt, daher mag ich das Produkt irgendwie).

Aber in der sich wandelnden Landschaft von heute reicht das nicht mehr aus, und der Grund dafür ist: Ze Cloud!

Wenn wir uns das lokale Rechenzentrum und die Cloud-Umgebung ansehen, gibt es viele Unterschiede bei den verwendeten Protokollen und Lösungen, die auf mehrere Gründe zurückzuführen sind, aber die 3 wichtigsten sind: Sicherheit, Datenschutz und Interoperabilität.

Wenn wir uns die Protokolle ansehen, die im lokalen Rechenzentrum für die Authentifizierung und Autorisierung verwendet werden, können wir mit Sicherheit sagen, dass Kerberos heute das am weitesten verbreitete Protokoll ist. Und wenn wir uns den Datenzugriff ansehen, der heute in Rechenzentren für den Zugriff auf den Identitätsspeicher verwendet wird, würde ich sagen, dass LDAP das am weitesten verbreitete Protokoll ist, das von fast jedem Verzeichnisanbieter unterstützt wird.

Das ist also genau das, was ADDS tut: Es authentifiziert Benutzer und autorisiert den Ressourcenzugriff über Kerberos und ermöglicht den Zugriff auf den Datenspeicher über das LDAP-Protokoll.

Aber dann kam die Cloud" (und Facebook, das eine sehr greifbare Verbindung hat)

Wenn man sich ansieht, wie AuthN und AuthZ in der Cloud verwaltet werden (bzw. nicht verwaltet werden), ist es ziemlich verständlich, dass Kerberos nicht gut genug ist.

Der Grund dafür ist, dass Sie bei der Verwendung von Kerberos Schlüssel angeben, die zur Verschlüsselung von Kerberos-Tickets verwendet und von einer einzigen autorisierten Quelle bereitgestellt werden. Das ist in einer Cloud-Umgebung nicht möglich (welche Schlüssel würden Sie verwenden, wenn Sie ein Facebook-Konto bei einem Google-Dienst authentifizieren wollen? Es gibt keinen zentralen Identitätsspeicher und keinen zentralen Schlüsselanbieter).

Dann kamen SAML, OAuth, OpenID und einige andere zur Rettung. All das sind Technologien, die eine föderierte Anmeldung ermöglichen. (Im Grunde genommen geht es darum, wie ich mich von Facebook bei Google anmelden kann, ohne meine Anmeldedaten zweimal eingeben zu müssen). Jede dieser Technologien hat ihre eigene Spezifikation, aber das Hauptziel ist es, die Authentifizierung über verschiedene Dienste von verschiedenen Dienst-/Cloud-Anbietern zu ermöglichen (habe ich schon die Interoperabilität erwähnt? ).

Für die Datenzugriffsschicht gilt das Gleiche. Obwohl LDAP funktionieren könnte, gibt es etwas, das bei der Verwaltung von Verbindungen zwischen Personen (egal, ob es sich um organisatorische Benutzer oder um Verbraucher mit Profilbildern und Wänden handelt) sinnvoller ist: der Graph!

Die Verwendung von Graph für einen Datenspeicher (insbesondere einen Identitätsspeicher) ist absolut sinnvoll, da er nicht hierarchisch aufgebaut ist wie LDAP und tatsächlich "Verbindungen" zwischen den Benutzern und den Ressourcen in der Organisation aufzeigen kann. So können Sie tatsächlich eine Identität verwalten und nicht eine ganze Hierarchie, die dazu dient, die Identitäten in "Ordnern" zu organisieren, je nachdem, was die Organisation für sinnvoll hält.

An dieser Stelle kommt Azure Active Directory ins Spiel. AAD ist ein cloudbasierter IDaaS (Identity as a Service) von Microsoft, der offene Standards (z.B. SAML) verwendet, um Benutzer zu authentifizieren und den Identitätsverbund zwischen Cloud-Diensten zu ermöglichen, sowie das Graph-Datenmodell, um Objekte abzufragen und zu verwalten.

Hier ist ein kurzer tabellarischer Vergleich der beiden:

Azure Active Directory Active Directory-Domänendienste
Bietet SSO und ein Benutzer-Repository für Cloud-Dienste. Bietet SSO und Identitätsmanagement für Dienste vor Ort.
Bieten Sie eine erweiterbare Plattform für die Rollenverwaltung vonDrittanbietern Bietet keine Möglichkeit zur Rollenverwaltung für Cloud-Dienste vonDrittanbietern
Bietet eine mandantenfähige Cloud-Identitätsplattform Verlassen Sie sich auf eine Plattform mit nur einem Mieter vor Ort
Verwendung von Industriestandards für die Cloud-Authentifizierung Verwendung von Industriestandards für die Authentifizierung vor Ort
Verwendet Graph API für den Datenzugriff Verwendet das LDAP-Protokoll für den Datenzugriff

Zusammenfassend lässt sich sagen, dass ADDS uns die Möglichkeit bietet, uns bei unserem Unternehmensnetzwerk anzumelden, auf die Ressourcen im Unternehmensnetzwerk zuzugreifen und den Diensten die Abfrage von Informationen über Objekte wie Benutzer, Gruppen und Ressourcen ermöglicht.

AAD ermöglicht die Anmeldung bei unseren Cloud-Diensten, den Zugriff auf Ressourcen in der Cloud und die Abfrage von Informationen über Objekte durch Cloud-Dienste.

Ich hoffe, das hat Ihnen geholfen, die beiden zu verstehen.

Im nächsten Beitrag werde ich versuchen zu erklären, wie beide miteinander verbunden werden können, um eine "hybride" Identität zu schaffen (eine Identität, die es erlaubt, dasselbe Konto sowohl für Ressourcen vor Ort als auch für Cloud-Dienste zu verwenden).