Bei der Identitätsföderation dreht sich alles um Vertrauen. Wie das Diagramm unten zeigt, bilden alle Teilnehmer einer solchen Identitätsföderation einen Kreislauf von Vertrauensbeziehungen. Man kann die Verbundauthentifizierung für Windows Azure Service Bus leicht auf externe Benutzergemeinschaften mit sozialer Identität, Windows Azure Active Directory (WAAD)-Mieter-Cloud-Identität oder Geschäftspartner-Identität erweitern. Außerdem werden Föderationsprotokolle wie SAML-P, WS-Fed und OpenID unterstützt.
Im obigen Szenario ist die Client-Anwendung als claim-aware implementiert und für die Endbenutzer mit der oben genannten föderierten Identität zugänglich. Sobald sich der Benutzer bei der Client-Anwendung anmeldet, nutzt er den Windows Azure Service Bus, um Geschäftsaufgaben auszuführen.
Active Directory Federation Service (ADFS) fungiert als Identitätsanbieter für interne Benutzer (Mitarbeiter) und als Security Token Service (STS) für externe Benutzer mit föderierter Identität. In diesem Beitrag wird der STS als Authentifizierungsbroker beschrieben, der nicht nur die Generierung von Sicherheitstoken, sondern auch den Austausch und die Übertragung von Sicherheitstoken übernimmt. Die Beziehung zwischen WAAD und Windows Azure Access Control Service (ACS) ist ähnlich wie bei ADFS als Identitätsanbieter
Rolle und als Sicherheits-Token-Service-Rolle. Darüber hinaus kann ACS auch eine Identitätsanbieterrolle sein, eine der STS-Rollen, mit eigenen Dienstidentitäten.
Damit ein Client mit Azure Service Bus arbeiten kann, kann er ein SAML-Token von ADFS erhalten. Der Client legt das SAML-Token dem automatisch erstellten Service Bus ACS (SB ACS) vor, um es als SWT-Token auszutauschen. Dann sendet der Client die Anfrage an Service Bus zusammen mit dem SWT-Token.
In der einfachsten Implementierung ist der Client durch ADFS als vertrauende Partei gesichert und erhält Ansprüche, sobald der Benutzer authentifiziert ist. Dann verwendet der Client WS-Trust, um von ADFS ein SAML-Token zu erhalten, das auf SB-ACS angewendet wird. Diese Implementierung trennt die Identität des Anrufers (die Identität mit den in WS-Trust verwendeten Anmeldeinformationen). Auch hier muss die Integrität zwischen diesen beiden getrennten Identitäten aufrechterhalten werden, wenn die Informationen über den Anspruch des Subjekts für den Dienst wichtig sind.
Alternativ kann sich der Client als Endbenutzer ausgeben, indem er die Rückgabe-URL als Mittel verwendet, um entweder ein SAML-Token, das auf SB-ACS angewendet wird, oder ein SWT-Token, das auf Azure Service Bus angewendet wird, innerhalb des Identitätskontextes des einzelnen Subjekts zu konsumieren.
Lassen Sie uns den Anwendungsfall des Geschäftspartners mit SAML-P Identity Provider durchgehen.
- Benutzer versucht, auf die Client-Anwendung zuzugreifen
- Client leitet unauthentifizierte Anfrage an ADFS um
- Der Benutzer wählt den SAML-P IdP während des Home Realm Discovery (HRD) Prozesses
- ADFS sendet SAMLRequest-Nachricht an SAML-P IdP
- SAML-P IdP authentifiziert den Benutzer
- SAML-P gibt SAML-Token an ADFS zurück
- ADFS generiert neues SAML-Token auf Basis von Anspruchsregeln
- Browser sendet automatisch neues SAML-Token an den Client
- Kunde präsentiert neues SAML-Token an SB-ACS
- SB-ACS tauscht SAML-Token als SWT-Token auf der Grundlage von Anspruchsregeln aus
- Client übergibt SWT-Token mit der Dienstanforderung an Azure Service Bus
- Azure Service Bus validiert das Token und ermöglicht die Weiterleitung der Anfrage an den gewünschten Dienst
Der gleiche Prozess geht von anderen Identitätsprovidern wie Social IdP oder WAAD Tenant Instance über Windows Azure ACS als Federation Provider zu ADFS. WAAD implementiert auch SAML-P als Identity Provider, sofern RelayState unterstützt wird. Für solche Fälle kann man eine Föderations-Vertrauensbeziehung zwischen WAAD als Identitätsprovider und ADFS als Serviceprovider unter Verwendung des SAML-P Terms einrichten.
