SAML 2.0-Web-Browser-SSO

Mit SAML-Web-Browser-SSO (Single Sign-on) können Webanwendungen die Authentifizierung von Benutzern an einen SAML-Identitätsprovider delegieren, anstatt dafür eine konfigurierte Benutzerregistry zu verwenden.

Security Assertion Markup Language (SAML) ist ein offener OASIS-Standard für die Darstellung und den Austausch von Benutzeridentität, Authentifizierung und Attributinformationen. Eine SAML-Zusicherung ist ein Token im XML-Format, das im Rahmen der Ausführung einer SSO-Anforderung zum Übertragen von Benutzeridentität und Attributinformationen vom Identitätsprovider eines Benutzers an einen anerkannten Service-Provider verwendet wird. Eine SAML-Zusicherung stellt eine anbieterunabhängige Methode für die Übertragung von Informationen zwischen Geschäftspartnern in einem Verband dar. Mit SAML kann ein Unternehmensservice-Provider einen eigenständigen Unternehmensidentitätsprovider kontaktieren, um Benutzer zu authentifizieren, die versuchen, auf sichere Inhalte zuzugreifen.

WebSphere Application Server Liberty unterstützt das SAML-Web-Browser-SSO-Profil mit HTTP-Post-Bindungen und fungiert als SAML-Service-Provider. Ein Webbenutzer authentifiziert sich bei einem SAML-Identitätsprovider, der eine SAML-Zusicherung erzeugt, und der WebSphere-SAML-Service-Provider verwendet die SAML-Zusicherung, um einen Sicherheitskontext für den Webbenutzer zu erstellen.

Der SAML-Web-SSO-Ablauf umfasst drei Akteure: den Endbenutzer, den Identitätsprovider (IdP) und den Service-Provider (SP). Der Benutzer authentifiziert sich immer beim IdP und der SP stützt sich zur Identifikation des Benutzers auf die IdP-Zusicherung.

Abbildung 1. Schlüsselkonzepte bei Web-SSO

Der SAML-Web-SSO-Ablauf umfasst drei Akteure: den Endbenutzer, den Identitätsprovider (IdP) und den Service-Provider (SP). Der Benutzer authentifiziert sich immer beim IdP und der SP stützt sich zur Identifikation des Benutzers auf die IdP-Zusicherung.

SAML-Web-Browser-SSO-Szenarien für Liberty

Abbildung 2. Szenario 1: Vom SP eingeleitetes angefordertes Web-SSO (Endbenutzer beginnt beim SP)
Vom SP eingeleitetes angefordertes Web-SSO (Endbenutzer beginnt beim SP)
  1. Der Endbenutzer besucht den SP.
  2. Der SP leitet den Benutzer an den IdP um.
  3. Der Endbenutzer authentifiziert sich beim IdP.
  4. Der IdP sendet die SAML-Antwort und -Zusicherung an den SP.
  5. Der SP überprüft die SAML-Antwort und berechtigt die Benutzeranforderung.
Abbildung 3. Szenario 2: Vom IdP eingeleitetes nicht angefordertes Web-SSO (Endbenutzer beginnt beim IdP)
Vom IdP eingeleitetes nicht angefordertes Web-SSO (Endbenutzer beginnt beim IdP)
  1. Der Benutzeragent greift auf den SAML-IdP zu.
  2. Der IdP authentifiziert den Benutzer und gibt eine SAML-Zusicherung aus.
  3. Der IdP leitet den Benutzer mit einer SAML-Antwort an den SP um.
  4. Der SP überprüft die SAML-Antwort und berechtigt die Benutzeranforderung.
Abbildung 4. Szenario 3: OpenID Connect-Provider und SAML-Service-Provider
OpenID Connect-Provider und SAML-Service-Provider
  1. Der Endbenutzer besucht die OpenID Connect-Relying-Party (RP).
  2. Die RP leitet den Endbenutzer an den OpenID Connect-Provider (OP) um.
  3. Der OP (auch SAML-SP) leitet den Endbenutzer an den SAML-IdP um.
  4. Der Endbenutzer authentifiziert sich beim SAML-IdP.
  5. Der IdP leitet den Endbenutzer mit einer SAML-Antwort an den OP oder SP um.
  6. Der OP/SP überprüft die SAML-Antwort und sendet einen Berechtigungscode an die RP.
  7. Die RP tauscht Code für das id_token (ID-Token) und das access_token (Zugriffstoken) aus.
  8. Die RP überprüft das id_token und berechtigt den Endbenutzer.

Symbol das den Typ des Artikels anzeigt. Konzeptartikel

Nutzungsbedingungen für Information Center | Feedback


Symbol für Zeitmarke Letzte Aktualisierung: 26.04.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-libcore-mp&topic=cwlp_saml_web_sso
Dateiname: cwlp_saml_web_sso.html