Microsoft Windows Azure Active Directory eröffnet Menschen und Organisationen die Möglichkeit, Anwendungen überall zu nutzen, basierend auf allgegenwärtiger Cloud-Konnektivität und offenen Standardprotokollen wie OAuth, SAML-P, WS-Federation und dem REST-API-Paradigma.
Es ist möglich, das folgende Anwendungsszenario zu realisieren, indem Azure Active Directory (AAD) Vorschau-Pakete mit diesen integrierten Technologien kombiniert werden.
Nehmen wir an, dass der Identitätsanbieter AAD als Identitätsspeicher mit URL-Endpunkten für Federation, Login und OAuth verwendet.
1. Der Benutzer dieses Identity Providers versucht, auf den Service Provider zuzugreifen.
2. Der Dienstanbieter zeigt eine Seite zur Ermittlung des Heimatbereichs an, auf der der Benutzer den Heimatbereich auswählen kann.
3. Der Benutzer wählt diesen Identitätsanbieter aus und wird mit SAML-P an den Identitätsanbieter weitergeleitet.
4. Der Identity Provider stellt fest, dass keine Sitzung existiert und delegiert den Authentifizierungsprozess an den AAD-Anmeldeendpunkt (mit der Vorschau können Sie die Office 365-Anmeldeseite nutzen).
5. AAD zeigt die Anmeldeseite an, auf der der Benutzer seine Anmeldedaten eingeben muss, und meldet den Benutzer an.
6. AAD POST das WS-Federation-Sicherheits-Token an den Identity Provider, der die Ansprüche mit den Informationen des authentifizierten Benutzers konsumiert.
7. Der Identitätsanbieter wandelt das Sicherheits-Token um und POST es an den Dienstanbieter.
8. Angenommen, der Dienstanbieter ist nicht in der Lage, das authentifizierte Konto dem Identitätskonto zuzuordnen.
9. Der Dienstanbieter startet den OAuth 2.0 JWT-Fluss, indem er mit AAD spricht, um Benutzerdaten über die Directory Graph API zu beziehen.
10. Jetzt richtet der Dienstanbieter das Konto für den authentifizierten Benutzer ein.
Ein anderes mögliches Anwendungsszenario kann wie folgt aussehen:
1. Der Benutzer dieses Identity Providers versucht, auf den Service Provider zuzugreifen.
2. Der Dienstanbieter zeigt eine Seite zur Ermittlung des Heimatbereichs an, auf der der Benutzer den Heimatbereich auswählen kann.
3. Der Benutzer wählt diesen Identity Provider aus und wird zum Anmeldeprozess des Identity Providers mit dem standardmäßigen OAuth 2.0-Autorisierungscode weitergeleitet.
4. Der Identity Provider stellt fest, dass keine Sitzung existiert und delegiert den Authentifizierungsprozess an den AAD-Anmeldeendpunkt.
5. AAD zeigt die Anmeldeseite an, auf der der Benutzer seine Anmeldedaten eingeben muss, und meldet den Benutzer an.
6. AAD POST das WS-Federation-Sicherheitstoken an den Identity Provider, der die Ansprüche mit den Informationen des authentifizierten Benutzers konsumiert.
7. Der Identity Provider fordert den OAuth-Zugangscode im Namen des authentifizierten Benutzers an, indem er den OAuth-Autorisierungsprozess an den AAD OAuth-Endpunkt delegiert.
8. Sobald der Identitätsserver den Zugriffscode erhält, leitet er an die vom Dienstanbieter übermittelte Umleitungs-URI weiter.
9. Nun fordert der Service Provider mit Hilfe des Autorisierungscodes ein Access Token vom Identity Provider an.
10. Der Identitätsanbieter durchläuft einen ähnlichen Prozess, indem er den OAuth-Prozess zur Anforderung des Zugriffstokens delegiert.
11. Sobald der Identitätsanbieter das Zugriffstoken erhalten hat, leitet er an die vom Dienstanbieter übergebene Umleitungs-URI weiter.
12. Der Dienstanbieter verwendet Zugriffstoken, die an den Ressourcenserver auf der Seite des Identitätsanbieters zurückgesendet werden, um authentifizierte Benutzerinformationen zu erhalten.