Einsatzszenarien für SAML

Die SAML-Funktion wird anhand von vier grundlegenden Einsatzszenarien beschrieben. Die ersten drei Szenarien veranschaulichen die einmalige Anmeldung (Single Sign-On, SSO) für Web-Services, die mit einem Richtliniensatz konfiguriert wird. Das vierte Szenario beschreibt das angepasste Single Sign-on für SAML, das Sie mit der SAML-API und der Trust-Client-API erstellen können. Die Szenarien veranschaulichen die Verwendung von SAML-Bausteinen und -APIs zur Authentifizierung bei einem Sicherheitstokenservice (Security Token Service, STS) sowie die Verwendung von SAML-Token für Anforderungen. Ferner beschreiben sie, wie SAML-Token zum Abrufen von Zugriffsberechtigungen für Geschäftsservices implementiert werden.

Übersicht

WebSphere Application Server mit SAML stellt Bausteine und APIs bereit, die Sie in die Lage versetzen, Geschäftslösungen für Single Sign-on und Identitätseinbindung mit SAML-Token zu erstellen. SAML-Richtliniensätze sind Bausteine für die Konfiguration von Web-Service-Anwendungen zur Anforderung von SAML-Token, zur Weitergabe von SAML-Token in SOAP-Nachrichten und zur Validierung und Authentifizierung von SAML-Token, die ohne jegliche Programmierung eingesetzt werden können.

Mit den SAML- und WS-Trust-Client-APIs können Sie SAML-Token programmgesteuert erstellen, SAML-Token syntaktisch analysieren und validieren und SAML-Token, die von Protokollen (außer Web-Service-SOAP-Nachrichten) empfangen wurden, authentifizieren. Verwenden Sie die SAML-APIs insbesondere, um angepasste SAML-Tokenattribute zu verarbeiten, personalisierte Anwendungsschnittstellen zu erstellen und eine Claim-basierte Autorisierung (Claim-Based Authorization) durchzuführen. Verwenden Sie die WS-Trust-Client-API, um SAML-Token oder andere Tokentypen von einem Sicherheitstokenservice (STS) anzufordern und Sicherheitstoken zu validieren und mit einem STS auszutauschen.

Das Produkt WebSphere Application Server enthält keinen STS für die Ausgabe von SAML-Token oder Sicherheitstoken anderer Typen. Allerdings interagiert WebSphere Application Server mit SAML mit Tivoli Federated Identity Manager und anderen STS-Implementierungen anderer Hersteller.

Szenario 1: SSO für Web-Services

In diesem Szenario zur Verwendung von SSO (Single Sign-On) authentifiziert ein Benutzer sich am STS und fordert SAML-Token mit der Bestätigungsmethode "bearer" an. Anschließend verwendet der Benutzer SAML-Token, um auf einen Geschäfts-Service-Provider zuzugreifen. Der Geschäfts-Service-Provider validiert die SAML-Token und sichert die Identität und Attribute des Benutzers basierend auf der Vertrauensbeziehung zwischen dem Provider und dem ausstellenden STS zu. Die empfangenen SAML-Token werden als gültig betrachtet, wenn die Signaturzertifikate des Tokens vom Geschäfts-Service-Provider anerkannt werden und der Wert für die Verfallszeit der Token kleiner ist als der Wert für die Ortszeit des Geschäfts-Service-Providers plus einer konfigurierbaren Zeitabweichung.

Der Geschäfts-Service-Provider kann für den Benutzer auf nachgeordnete Services zugreifen, indem er SAML-Token auf der Basis der Richtlinienkonfiguration des Service verwendet. Mit der Richtlinienkonfiguration kann der Geschäfts-Service-Provider die ursprünglichen SAML-Token weitergeben oder selbst ausgestellte SAML-Token auf der Basis der ursprünglichen Benutzerattribute generieren. Detaillierte Informationen zur Konfiguration von Richtliniensätzen und Bindungen für dieses Szenario finden Sie in den Artikeln, die sich mit der Konfiguration von Client- und Providerbindungen für das SAML-Bearer-Token (Trägertoken) befassen.

Single Sign-On mit einem SAML-Bearer-Token hat Vorteile gegenüber anderen SSO-Technologien, weil SAML ein branchenübliches Sicherheitstoken ist und von Produkten verschiedener Hersteller unterstützt wird. Außerdem interagiert die Implementierung der SAML-Funktion von WebSphere Application Server mit Tivoli Federated Identity Manager, DataPower und Produkten anderer Hersteller.

Die folgende Abbildung zeigt die Interaktion zwischen dem STS und dem Geschäfts-Service-Provider in dem Szenario zur Verwendung von SSO für Web-Services.
Abbildung 1. Einsatzszenario: SSO für Web-Services
Szenario: SSO mit SAML-Bearer-Token

Sie können eine Caller-Bindung zu den Beispielbindungen für den SAML-Provider hinzufügen, um das empfangene SAML-Token, das die Caller-Identität repräsentiert, auszuwählen. Die WS-Security-Laufzeitumgebung verwendet die SAML-Namens-ID, um die Clientidentität zu repräsentieren und den Sicherheitsnamen des Benutzers und die Gruppenzugehörigkeit im konfigurierten Benutzerrepository zu suchen, wenn Sie die standardmäßig verwendete JAAS-Anmeldekonfiguration "system.wss.caller" verwenden.

Nachdem dieses Szenario ausgeführt wurde, speichert die WS-Security-Laufzeitumgebung die SAML-Token und kann sie für den Zugriff auf denselben Geschäfts-Service-Provider wiederverwenden, falls die Token noch gültig sind. Ein Token ist gültig, falls der Wert für die Verfallszeit des Tokens kleiner ist als der konfigurierbare Wert für den Cachezeitraum. Nachdem der Geschäfts-Service-Provider die empfangenen SAML-Token authentifiziert und validiert hat, werden die JAAS-Subjekte zusammen mit den entsprechenden SAML-Token im Authentifizierungscache gespeichert. Die SAML-Token bleiben unabhängig von ihrer Verfallszeit im Hostanwendungsserver gültig. Das bedeutet, dass die WS-Security-Laufzeitumgebung die Verfallszeit eines SAML-Tokens nicht innerhalb desselben Prozesses prüft, da SAML-Token im Anwendungsserverprozess so lange gültig bleiben, wie sie sich im Authentifizierungscache befinden.

Verfallszeiten für SAML-Token werden geprüft, wenn der Geschäfts-Service-Provider die SAML-Token verwendet, um nachgeordnete Services aufzurufen. Abgehende Anforderungen schlagen fehl, wenn der Wert für die Verfallszeit des SAML-Tokens nicht kleiner ist als der Wert für die aktuelle Zeit plus dem Cachezeitraum. Diese Einschränkung gilt auch dann, wenn die Richtlinienkonfiguration die Verwendung der ursprünglichen SAML-Token voraussetzt. Sie gilt nicht, wenn die Richtlinienkonfiguration selbst ausgestelte SAML-Token verwendet, z. B., wenn der Geschäfts-Service-Provider eine Reproduktion der ursprünglichen SAML-Token erstellt und signiert hat.

Szenario 2: SSO für Web-Services mit Validierung vom Typ "holder-of-key"

Das Einsatzszenario für SSO mit Validierung vom Typ "holder-of-key" ähnelt dem vorherigen Einsatzszenario für SSO. Es verwendet SAML-Token mit der Bestätigungsmethode "holder-of-key" (HoK) anstelle der Bestätigungsmethode "bearer". SAML-HoK-Token enthalten einen Schlüssel, den der Client verwendet, um das Eigentumsrecht am Schlüssel und am Token nachzuweisen. Dieser integrierte Schlüssel kann ein gemeinsam genutzter Schlüssel (auch bezeichnet als symmetrischer Schlüssel) oder ein X.509-Zertifikat mit einem öffentlichen Schlüssel (auch bezeichnet als asymmetrischer Schlüssel) sein. Im Falle eines gemeinsam genutzten Schlüssels wird der Schlüssel mit dem öffentlichen Schlüssel des Ziel-Geschäfts-Service-Providers verschlüsselt, damit nur der gewünschte Geschäfts-Service-Provider die SOAP-Nachrichten konsumieren kann.

Wenn ein Client SAML-Token mit dem gemeinsam genutzten HoK-Schlüssel eines STS anfordert, verschlüsselt der STS den Schlüssel in den SAML-Token und sendet eine Kopie desselben Schlüssels in der WS-Trust-Antwort an den anfordernden Client. Dies ist notwendig, weil der Client sonst die verschlüsselten Schlüssel in den SAML-Token nicht lesen kann. Um das Eigentumsrecht an den SAML-Token nachzuweisen, verwendet der Client den gemeinsam genutzten Schlüssel zum Signieren und Verschlüsseln der SOAP-Anforderungsnachrichten. Geschäftsservices müssen das Eigentumsrecht am HoK-Token validieren, indem sie den verschlüsselten gemeinsam genutzten Schlüssel extrahieren und die digitale Signatur prüfen.

In der folgenden Abbildung ist zu sehen, wie ein Web-Service ein SAML-Token im Szenario anfordern kann.
Abbildung 2. Web-Service 1 fordert ein SAML-Token von einem externen Service an
Szenario: SSO mit Validierung vom Typ "holder-of-key"

 1  Der Benutzer meldet sich über einen Web-Server mit SPNEGO an und ist authentifiziert. Es wird ein JAAS-Subjekt erstellt.

 2  Der Berechtigungsnachweis vom SPNEGO-Token wird verwendet, um ein SAML-Token mit WS-Trust anzufordern. Das Token wird mit dem privaten Schlüssel des Trust-Servers signiert.

 3  Die Signatur des SAML-Tokens wird auf der Basis der Vertrauensbeziehung validiert. Der Sicherheitsberechtigungsnachweis wird mit den Attributen aus dem SAML-Token erstellt. Der Chiffrierschlüssel aus dem SAML-Token wird verwendet, um die SOAP-Nachricht zu entschlüsseln.

Wie im Diagramm gezeigt, verwendet ein Browser-Client Kerberos-Berechtigungsnachweise (dargestellt durch das SPNEGO-Token), um auf eine Webanwendung zuzugreifen. Vorausgesetzt, der Kerberos-Berechtigungsnachweis kann delegiert werden, kann die Webanwendung mit diesem Nachweis ein SAML-Token für den Client aus dem STS anfordern. Beispiel: Die Webanwendung ruft für den Client aus dem Key-Distribution-Center ein Kerberos-Token für eine Clientfreigabeanforderung ab. Die Webanwendung verwendet dann das Token für die Clientfreigabeanforderung, um sich am STS zu authentifizieren und für den Client ein Client-SAML-Token aus dem STS abzurufen.

In diesem Beispiel setzt das SAML-Token die Bestätigungsmethode "holder-of-key" mit einem symmetrischen Schlüssel voraus. Die Webanwendung verwendet das SAML-Token für den Zugriff auf nachgeordnete Geschäftsservices, ebenfalls für den Client, damit das SAML-Token den Client bei nachgeordneten Services authentifiziert und außerdem die Anforderungsnachrichten mit digitaler Signatur und Verschlüsselung schützt. Weitere Informationen zur Konfiguration von Bindungen für das HoK-Token finden Sie in den Artikeln, die sich mit der Konfiguration von Client- und Providerbindungen für das SAL-HoK-Token (Holder-of-key) mit symmetrischem Schlüssel befassen.

Nach erfolgreicher Ausführung des Szenarien können die Zielgeschäftsservices das SAML-Token verwenden, um mit derselben Prozedur auf andere nachgeordnete Services zuzugreifen, vorausgesetzt, die nachgeordneten Geschäftsservices können den integrierten Schlüssel extrahieren. Alternativ dazu können die Geschäftsservices konfiguriert werden, die selbst ausgestellten SAML-Token für den Zugriff auf nachgeordnete Services zu verwenden, um die Verteilung des privaten Schlüssels zu vermeiden.

Szenario 3: Verbundidentitätsverwaltung für Web-Services

Im Einsatzszenario für Verbundidentitätsverwaltung greift ein Browser-Client auf eine Portalwebanwendung eines Unternehmens zu. In diesem Szenario werden die grundlegenden Daten zur Benutzerauthentifizierung, wie z. B. Benutzername und Kennwort, verwendet, um SAML-Token aus einem STS anzufordern. Anschließend werden die SAML-Token verwendet, um in verschiedenen Sicherheitsdomänen auf Geschäftsservices zuzugreifen. Der empfangende Geschäfts-Service-Provider validiert die SAML-Token basierend auf der Vertrauensbeziehung zwischen dem Provider und dem ausstellenden STS, und der Provider sichert außerdem die Identität und die Attribute des Benutzers zu. Das bedeutet, dass der Benutzer nicht vorab im Benutzerverzeichnis in den Zielgeschäftsservices definiert werden muss. Ein Vorteil dieses Szenarien besteht darin, dass Geschäftsservices vieler Geschäftspartner einfach miteinander verbunden werden können, ohne dass Benutzer in einem Verzeichnisservice konsolidiert werden müssen.

Abbildung 3. Ein Benutzer meldet sich an einem Unternehmensportal an und verwendet die Verbundidentitätsverwaltung, um auf Geschäftsservices zuzugreifen
Szenario: Verbundidentitätsverwaltung

 1  Der Benutzer meldet sich mit einem Benutzernamen und einem Kennwort an und wird beim Unternehmensportal authentifiziert. Es wird ein JAAS-Subjekt erstellt.

 2  Der Benutzername und das Kennwort werden verwendet, um die Authentifizierung am STS durchzuführen und ein SAML-Token, das den Benutzer repräsentiert, anzufordern.

 3  Die Signatur des SAML-Tokens wird auf der Basis der Vertrauensbeziehung validiert. Es werden Sicherheitsberechtigungsnachweise mit den Attributen aus dem SAML-Token erstellt. Der Chiffrierschlüssel aus dem SAML-Token wird verwendet, um die SOAP-Nachricht zu entschlüsseln.

Die standardmäßig verwendete Systemanmeldekonfiguration, "wss.caller", ordnet die von SAML-Token dargestellten Benutzeridentitäten den im Benutzerverzeichnis konfigurierten Benutzeridentitäten zu. Der Anmeldekonfiguration "wss.caller" muss ein angepasstes Anmeldemodul hinzugefügt werden, um dem Anwendungsserver Benutzeridentitäten von SAML-Token aus anderen Sicherheitsdomänen zuzusichern. Dieses angepasste Anmeldemodul extrahiert die Benutzeridentität des SAML-Tokens und andere Attribute und erstellt die vom Anwendungsserver verwendeten Zusicherungseigenschaften. Zwei dieser Eigenschaften, Benutzername und Benutzeridentität, werden vom Anwendungsserver vorausgesetzt. Da die zwei Eigenschaften in der Identitätszusicherung bereitgestellt werden, ist es nicht erforderlich, dass der Anwendungsserver den Benutzernamen über einen Vergleich mit dem lokalen Benutzerverzeichnis validiert.

Darüber hinaus können dem Anwendungsserver Informationen zur Gruppenzugehörigkeit von Benutzern bereitgestellt werden. Diese Informationen werden verwendet, um das Objekt WSCredential, das die Sicherheitsberechtigungen des Anwendungsservers repräsentiert, für den Benutzer zu erstellen. Die Benutzereigenschaften werden über den gemeinsamen JAAS-LoginContext-Status an das WSWSSLoginModule des Anwendungsservers übergeben. Ausführliche Informationen zu diesen Eigenschaften finden Sie im Artikel zur Konfiguration eingehender Identitätszuordnungen.

Szenario 4: Angepasste SSO-Lösungen

Das Einsatzszenario mit angepasstem Single-Sign On (SSO) verwendet die APIs der SAML-Tokenbibliothek, die WS-Trust-Client-APIs und andere Anwendungsserver-APIs und -SPIs, um angepasste SSO-Lösungen für eine bestimmte geschäftliche Datenverarbeitungsumgebung zu erstellen. Die Abbildung zu diesem Szenario veranschaulicht, wie Benutzer authentifiziert werden, und zeigt SAML-Token, die von einem Identitätsprovider, der eine Vertrauensbeziehung zu einem Unternehmensserver hat, ausgegeben wurden. In diesem Szenario will ein Unternehmen basierend auf der bestehenden Vertrauensbeziehung Benutzern Zugriff auf geschützte Webanwendungen gewähren, ohne dass die Benutzer sich zusätzlich authentifizieren müssen.

Webanwendungsclients, wie z. B. Web-Browser, übergeben SAML-Token an den Anwendungsserver und verwenden dazu das Protokoll HTTPS anstelle des Web-Service-Protokolls. Um diese Anforderungen abfangen und weitergeben zu können, erstellt das Unternehmen einen Trust-Association-Interceptor (TAI) für SAML, der die TAI-API des Anwendungsservers implementiert. Ein SAML-TAI verwendet die API der SAML-Tokenbibliothek, um SAML-Token zu validieren und zu authentifizieren. Alternativ dazu kann der SAML-TAI die WS-Trust-Client-API verwenden, um SAML-Token für einen externen STS zu authentifizieren und zu validieren. Ausführlichere Informationen zur TAI-Schnittstelle finden Sie im Artikel "Einen eigenen Interceptor für Trust-Associations entwickeln". Ein angepasster SAML-TAI gehört nicht zum Lieferumfang von WebSphere Application Server.

Abbildung 4. Ein Benutzer meldet sich über einen Web-Browser mit dem Protokoll HTTPS an einem Unternehmensserver an und wird mit einem SAML-TAI authentifiziert
Szenario: Angepasstes SSO

 1  Der Benutzer meldet sich mit einem Benutzernamen und einem Kennwort bei einem Identitätsprovider an. Der Identitätsprovider stellt dem Benutzer ein SAML-Token aus.

 2  Der SAML-TAI verwendet die API SAMLTokenFactory, um das SAML-Token zu validieren und zwecks Erstellung von Benutzerberechtigungen zu authentifizieren. Alternativ dazu kann der SAML-TAI die WS-Trust-Client-API verwenden, um das SAML-Token für einen externen STS zu validieren.

Weitere Informationen zu den SAML-APIs finden Sie in den Artikeln zur WS-Trust-Client-API und den APIs der SAML-Tokenbibliothek.

Komplexere Lösung: Mehrere Sicherheitsdomänen

In den vorherigen Abschnitten dieses Dokuments wurden die vier Basiseinsatzszenarien beschrieben. Sie können SAML-Token jedoch auch über die Grenzen mehrerer Sicherheitsdomänen hinweg zusichern. Weitere Informationen zu dieser Lösung finden Sie in der Dokumentation zu SAML-Zusicherungen für mehrere Sicherheitsdomänen von WebSphere Application Server.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



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