Single Sign-On für HTTP-Anforderungen mit SPNEGO-Webauthentifizierung
Sie können HTTP-Anforderungen für gesicherte Ressourcen in WebSphere Application Server sicher vereinbaren und authentifizieren, indem Sie Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) als Webauthentifizierungsservice für WebSphere Application Server verwenden.
- Über die Administrationskonsole können Sie die SPNEGO-Webauthentifizierung und Filter in WebSphere Application Server konfigurieren und aktivieren.
- Das dynamische Neuladen von SPNEGO erfordert nicht mehr, dass WebSphere Application Server gestoppt und neu gestartet werden muss.
- Wenn die SPNEGO-Webauthentifizierung scheitert, kann auf eine Anwendungsanmeldemethode zurückgegriffen werden.
- SPNEGO kann auf Ebene der WebSphere-Sicherheitsdomäne angepasst werden. Weitere Informationen hierzu enthält der Artikel Mehrere Sicherheitsdomänen.
Sie können den SPNEGO TAI oder die SPNEGO-Webauthentifizierung aktivieren, jedoch nicht beide gleichzeitig.
In den folgenden Abschnitten ist die SPNEGO-Webauthentifizierung ausführlicher beschrieben:
- Was ist SPNEGO?
- Vorteile der SPNEGO-Webauthentifizierung
- SPNEGO-Webauthentifizierung in einem einzigen Kerberos-Realm
- SPNEGO-Webauthentifizierung in einem anerkannten Kerberos-Realm
- Unterstützungsinformationen für die SPNEGO-Webauthentifizierung mit einem Java-Client mit dem HTTP-Protokoll
- Unterstützungsinformationen für die SPNEGO-Webauthentifizierung mit einem Browserclient
- SPNEGO als Authentifizierungsverfahren für WebSphere Application Server konfigurieren
Was ist SPNEGO?
SPNEGO ist eine im IETF-RFC 2478, Simple and Protected GSS-API Negotiation, definierte Standardspezifikation.
Wenn die globale Sicherheit und die Anwendungssicherheit in WebSphere Application Server aktiviert sind und außerdem die SPNEGO-Webauthentifizierung aktiviert ist, wird SPNEGO initialisiert, wenn die erste eingehende HTTP-Anforderung verarbeitet wird. Der Webauthentifikator interagiert mit dem SPNEGO, der im Sicherheitskonfigurationsrepository definiert und aktiviert ist. Wenn die Filterkriterien erfüllt sind, ist SPNEGO für die Authentifizierung des Zugriffs auf die geschützten Ressourcen zuständig, die in der HTTP-Anforderung angegeben sind.
Microsoft Windows-Server mit Active Directory-Domäne und zugehörigem Kerberos-Key-Distribution-Center (KDC). Informationen über die unterstützten Microsoft Windows-Server finden Sie in den Systemvoraussetzungen für WebSphere Application Server Version 9.0 unter Windows.
- Eine Clientanwendung, z. B. Microsoft .NET oder ein Web-Service und ein J2EE-Client, der das Webauthentifizierungsverfahren SPNEGO gemäß IETF RFC 2478 unterstützt. Beispiele für Browser sind Microsoft Internet Explorer ab Version 5.5 oder Mozilla Firefox Version 1.0. Jeder Browser muss für die Verwendung des SPNEGO-Webauthentifizierungsverfahrens konfiguriert werden. Nähere Informationen zu dieser Konfiguration finden Sie im Artikel Client-Browser für die Verwendung von SPNEGO konfigurieren.
Die Authentifizierung von HTTP-Anforderungen wird vom Anforderer (der Clientseite) durch die Generierung eines SPNEGO-Tokens ausgelöst. WebSphere Application Server empfängt dieses Token. Die SPNEGO-Webauthentifizierung decodiert dazu die Identität des Anforderers und ruft diese dann aus dem SPNEGO-Token ab. Mit dieser Identität wird ein sicherer Kontext zwischen dem Anforderer und dem Anwendungsserver etabliert.
Die SPNEGO-Webauthentifizierung ist in WebSphere Application Server eine serverseitige Lösung. Clientseitige Anwendungen müssen das SPNEGO-Token für die SPNEGO-Webauthentifizierung generieren. Die Identität des Anforderers in der Sicherheitsregistry von WebSphere Application Server muss mit der von der SPNEGO-Webauthentifizierung abgerufenen Identität übereinstimmen. Diese Übereinstimmung ist gewährleistet, wenn der Active Directory Server von Microsoft Windows der in WebSphere Application Server verwendete LDAP-Server ist. Zur Unterstützung einer angepassten Zuordnung von Identitäten in Active Directory zur Sicherheitsregistry von WebSphere Application Server ist ein angepasstes Anmeldemodul als Plug-in verfügbar.
Weitere Informationen zu diesem angepassten Anmeldemodulfinden Sie im Artikel
Kerberos-Client-Principal-Namen der ID für die WebSphere-Benutzerregistry zuordnen.
WebSphere Application Server überprüft die Identität in seiner Sicherheitsregistry. Wenn diese Validierung erfolgreich ist, werden das Kerberos-Clientticket und der Berechtigungsnachweis für GSS-Delegierung abgerufen und in das Clientsubjekt kopiert. Dies ergibt ein LTPA-Sicherheitstoken (Lightweight Third Party Authentication). Anschließend wird ein Cookie kopiert und an den Anforderer in der HTTP-Antwort zurückgegeben. Wenn derselbe Anforderer nachfolgend HTTP-Anforderungen hinsichtlich des Zugriffs auf weitere geschützte Ressourcen in WebSphere Application Server stellt, wird das zuvor erstellte LTPA-Sicherheitstoken verwendet, um wiederholte Anmeldeanforderungen zu vermeiden.
Der Webadministrator kann auf die in der folgenden Abbildung dargestellten SPNEGO-Sicherheitskomponenten und die zugehörigen Konfigurationsdaten zugreifen:

Vorteile der SPNEGO-Webauthentifizierung
Im Folgenden sind einige Vorteile des Einsatzes von Kerberos als Authentifizierungsverfahren für WebSphere Application Server beschrieben:
Es wird eine integrierte SSO-Umgebung in Microsoft Windows-Servern unter Verwendung der Active Directory-Domäne erstellt.
- Die Kosten für die Verwaltung einer großen Anzahl von IDs und Kennwörtern sinken.
- Es wird eine sichere Übertragung von Sicherheitsberechtigungsnachweisen vom Web-Browser oder von Microsoft-.NET-Clients mit gegenseitiger Authentifizierung ermöglicht.
- Es besteht Interoperabilität mit Web-Services und Microsoft-.NET-Anwendungen oder Web-Service-Anwendungen, die die SPNEGO-Authentifizierung auf Transportebene verwenden.
- Zusammen mit der Unterstützung der Kerberos-Authentifizierung kann die SPNEGO-Webauthentifizierung eine End-to-End-SPNEGO-Kerberos-Lösung bilden und den Kerberos-Berechtigungsnachweis vom Client übernehmen.
SPNEGO-Webauthentifizierung in einem einzigen Kerberos-Realm
Die SPNEGO-Webauthentifizierung wird in einem einzigen Kerberos-Realm unterstützt. Der Handshake-Prozess für diese Anforderungen und Antworten ist in der folgenden Abbildung dargestellt.

In der vorherigen Abbildung werden die folgenden Ereignisse gezeigt:
- Der Client sendet eine HTTP/Post/Get/Web-Service-Anforderung an WebSphere Application Server.
- WebSphere Application Server gibt HTTP 401 Authenticate/Negotiate zurück.
- Der Client ruft ein Ticket-Granting-Ticket (TGT) ab.
- Der Client fordert ein Serviceticket (TGS_REQ) an.
- Der Client ruft ein Serviceticket ab (TGS_REP).
- Der Client sendet HTTP/Post/Get/Web-Service und ein SPNEGO-Berechtigungstoken an WebSphere Application Server.
- WebSphere Application Server validiert das SPNEGO-Token. Wenn die Validierung erfolgreich ist, werden die Benutzer-ID und der Berechtigungsnachweis für GSS-Delegierung aus dem SPNEGO-Token abgerufen. Erstellen Sie ein KRBAuthnToken mit einem Client-Kerberos-Berechtigungsnachweis.
- WebSphere Application Server überprüft die Benutzer-ID in der WebSphere-Benutzerregistry und erstellt ein LTPA-Token.
- WebSphere Application Server gibt HTTP 200, Inhalt und das LTPA-Token an den Client zurück.
SPNEGO-Webauthentifizierung in einem anerkannten Kerberos-Realm
Die SPNEGO-Webauthentifizierung wird auch in einem anerkannten Kerberos-Realm unterstützt. Der Handshake-Prozess für diese Anforderungen und Antworten ist in der folgenden Abbildung dargestellt.

In der vorherigen Abbildung werden die folgenden Ereignisse gezeigt:
- Der Client sendet eine HTTP/Post/Get/Web-Service-Anforderung an WebSphere Application Server.
- WebSphere Application Server gibt HTTP 401 Authenticate/Negotiate zurück.
- Der Client ruft ein Ticket-Granting-Ticket (TGT) ab.
- Der Clientanforderung fordert ein realmübergreifendes Ticket (TGS_REQ) für REALM2 vom KDC von REALM1 an.
- Der Client verwendet das realmübergreifende Ticket aus Schritt 4, um ein Serviceticket vom KDC von REALM2 anzufordern.
- Der Client sendet HTTP/Post/Get/Web-Service und ein SPNEGO-Berechtigungstoken an WebSphere Application Server.
- WebSphere Application Server validiert das SPNEGO-Token. Wenn die Validierung erfolgreich ist, werden die Benutzer-ID und der Berechtigungsnachweis für GSS-Delegierung aus dem SPNEGO-Token abgerufen. Erstellen Sie ein KRBAuthnToken mit einem Client-Kerberos-Berechtigungsnachweis.
- WebSphere Application Server überprüft die Benutzer-ID in der WebSphere-Benutzerregistry und erstellt ein LTPA-Token.
- WebSphere Application Server gibt HTTP 200, Inhalt und das LTPA-Token an den Client zurück.
In einer Umgebung mit anerkannten Kerberos-Realms müssen Sie Folgendes beachten:
- Die Konfiguration der anerkannten Kerberos-Realms muss in jedem Kerberos-KDCs durchgeführt werden. Weitere Informationen zum Konfigurieren anerkannter Kerberos-Realms finden Sie in Ihrem Kerberos-Handbuch für Administratoren und Benutzer.
- Der Principal-Name des Kerberos-Clients aus dem SPNEGO-Token ist möglicherweise nicht in der
WebSphere-Benutzerregistry enthalten
und muss deshalb
der WebSphere-Benutzerregistry zugeordnet werden.
Weitere Informationen finden Sie im Artikel
Kerberos-Client-Principal-Namen der ID für die WebSphere-Benutzerregistry zuordnen.
Unterstützungsinformationen für die SPNEGO-Webauthentifizierung mit einem Java™-Client mit dem HTTP-Protokoll
- Anerkennung von Domänen in derselben Gesamtstruktur
- Anerkennung externer Domänen, die direkt zwischen Domänen in verschiedenen Gesamtstrukturen erfolgt.
- Anerkennung von Kerberos-Realms
- Strukturübergreifende Anerkennung
- Anerkennung externer Gesamtstrukturen
Unterstützungsinformationen für die SPNEGO-Webauthentifizierung mit einem Browserclient
- Strukturübergreifende Anerkennung
- Anerkennung von Domänen in derselben Gesamtstruktur
- Anerkennung von Kerberos-Realms
- Anerkennung externer Gesamtstrukturen
- Anerkennung externer Domänen