Single Sign-On für HTTP-Anforderungen mit SPNEGO-Webauthentifizierung
Sie können HTTP-Anforderungen für geschützte Ressourcen in WebSphere® Application Server sicher vereinbaren und authentifizieren, indem Sie SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) als Webauthentifizierungsservice für WebSphere Application Serververwenden.
In den folgenden Abschnitten ist die SPNEGO-Webauthentifizierung ausführlicher beschrieben:
Was ist SPNEGO?
SPNEGO ist eine Standardspezifikation, die in The Simple and Protected GSS-API Negotiation Mechanism (IETF RFC 2478)definiert ist.
Wenn die Sicherheit des Liberty -Servers und die SPNEGO-Webauthentifizierung aktiviert sind, wird SPNEGO initialisiert, wenn eine erste eingehende HTTP-Anforderung verarbeitet wird. Wenn kein Authentifizierungsfilter angegeben ist oder der Authentifizierungsfilter angegeben ist und die Kriterien erfüllt sind, ist SPNEGO für die Authentifizierung des Zugriffs auf die in der HTTP-Anforderung bezeichnete geschützte Ressource zuständig.
- Microsoft Windows Server mit Active Directory -Domäne und zugeordnetem Kerberos Key Distribution Center (KDC).
- Eine Clientanwendung, z. B. Microsoft .NET, oder ein Web-Service und ein J2EE -Client, der das SPNEGO-Webauthentifizierungsverfahren gemäß IETF RFC 2478 unterstützt. Microsoft Internet Explorer und Mozilla Firefox sind Browserbeispiele. Jeder verwendete Browser muss für die Verwendung des SPNEGO-Webauthentifizierungsverfahrens konfiguriert sein.
Die Authentifizierung von HTTP-Anforderungen wird von dem Benutzer (Clientseite) ausgelöst, der ein SPNEGO-Token generiert. WebSphere Application Server empfängt dieses Token. Die SPNEGO-Webauthentifizierung entschlüsselt die Benutzeridentität aus dem SPNEGO-Token und ruft diese ab. Anhand der Identität werden dann Berechtigungsentscheidungen getroffen.
Die SPNEGO-Webauthentifizierung ist eine serverseitige Lösung in WebSphere Application Server. Clientseitige Anwendungen müssen das SPNEGO-Token für die SPNEGO-Webauthentifizierung generieren. Die Benutzeridentität in der Sicherheitsregistry von WebSphere Application Server muss mit der Identität identisch sein, die von der SPNEGO-Webauthentifizierung abgerufen wird. Eine identische Übereinstimmung tritt auf, wenn Microsoft Windows Active Directory -Server der LDAP-Server (Lightweight Directory Access Protocol) ist, der in WebSphere Application Serververwendet wird. Ein angepasstes Anmeldemodul ist als Plug-in verfügbar, um die angepasste Zuordnung der Identität aus Active Directory zur WebSphere Application Server -Sicherheitsregistry zu unterstützen.
WebSphere Application Server validiert die Identität anhand ihrer Sicherheitsregistry. Wenn die Auswertung erfolgreich ist, wird der Clientberechtigungsnachweis für die GSS-Delegierung abgerufen und in das Clientsubjekt aufgenommen. Außerdem wird ein LTPA-Sicherheitstoken erstellt. Anschließend wird das LTPA-Cookie in der HTTP-Antwort an den Benutzer zurückgegeben. Nachfolgende HTTP-Anforderungen desselben Benutzers für den Zugriff auf mehr geschützte Ressourcen in WebSphere Application Server verwenden das zuvor erstellte LTPA-Sicherheitstoken, um wiederholte Anmeldeanforderungen zu vermeiden.
SPNEGO-Webauthentifizierung in einem einzigen Kerberos-Realm
Die SPNEGO-Webauthentifizierung wird in einem einzelnen Kerberos-Realm (Domäne) unterstützt. Der Handshake-Prozess für diese Anforderungen und Antworten ist in der folgenden Abbildung dargestellt.
In der obigen Abbildung kommt es zu folgenden Ereignissen:
- Zu Beginn meldet sich der Benutzer über die Workstation am Microsoft-Domänencontroller
MYDOMAIN.EXAMPLE.COM
an. - Anschließend versucht der Benutzer, auf die Webanwendung zuzugreifen. Der Benutzer fordert eine geschützte Webressource über einen Client-Browser an, der eine
HTTP GET
-Anforderung an den Liberty -Server sendet. - Die SPNEGO-Authentifizierung im Liberty -Server beantwortet den Client-Browser mit einem
HTTP 401
-Anforderungsheader, der den StatusAuthenticate: Negotiate
enthält. - Der Client-Browser erkennt den Verhandlungsheader, da der Client-Browser für die Unterstützung der integrierten Windows-Authentifizierung konfiguriert ist. Der Client analysiert die angeforderte URL, um den Hostnamen zu ermitteln. Der Client verwendet den Hostnamen, um den Ziel- Kerberos Service-Principal-Namen (SPN)
HTTP/myLibertyMachine.example.com
zu bilden, um ein Kerberos -Service-Ticket vom Kerberos -Ticket-granting Service (TGS
) im Microsoft Kerberos -KDC (TGS_REQ
) anzufordern. Anschließend gibtTGS
ein Kerberos -Service-Ticket (TGS_REP
) an den Client aus. Das Kerberos -Service-Ticket (SPNEGO-Token) beweist sowohl die Identität des Benutzers als auch die Berechtigungen für den Service (Liberty -Server). - Der Client-Browser antwortet dann auf die Abfrage "Authenticate: Negotiate" des Liberty -Servers mit dem SPNEGO-Token, das im vorherigen Schritt im HTTP-Header der Anforderung abgerufen wurde.
- Die SPNEGO-Authentifizierung im Liberty -Server sieht den HTTP-Header mit dem SPNEGO-Token, validiert das SPNEGO-Token und ruft die Identität (Principal) des Benutzers ab.
- Nachdem der Liberty -Server die Identität des Benutzers abgerufen hat, validiert er den Benutzer in seiner Benutzerregistry und führt die Berechtigungsprüfungen durch.
- Wenn der Zugriff erteilt wird, sendet der Liberty -Server die Antwort mit
HTTP 200
. Der Liberty -Server enthält auch ein LTPA-Cookie in der Antwort. Dieses LTPA-Cookie wird für nachfolgende Anforderungen verwendet.
SPNEGO-Webauthentifizierung in anerkannten Kerberos-Realms
Die SPNEGO-Webauthentifizierung wird auch in anerkannten Kerberos-Realms unterstützt. Der Handshake-Prozess für diese Anforderungen und Antworten ist in der folgenden Abbildung dargestellt.
In der obigen Abbildung kommt es zu folgenden Ereignissen:
- Der Benutzer meldet sich beim Microsoft-Domänencontroller
TRUSTEDREALM.ACME.COM
an. - In einem Client-Browser stellt der Benutzer eine Anforderung für eine geschützte Webressource, die auf einem Liberty -Server im ursprünglichen Microsoft-Domänencontroller
MYDOMAIN.EXAMPLE.COM
gehostet wird. - Der Liberty -Server beantwortet den Client-Browser mit einem HTTP 401-Abfrage-Header, der den Status
Authenticate: Negotiate
enthält. - Der Client-Browser ist für die Unterstützung der integrierten Windows-Authentifizierung konfiguriert. Der Client-Browser analysiert die URL mithilfe des Hostnamens der Workstation, die die Liberty -Serveranwendung hostet. Der Client-Browser verwendet den Hostnamen als Attribut, um
ein realmübergreifendes Kerberos-Ticket (
TGS_REQ
) fürMYDOMAIN.EXAMPLE.COM
vom RealmTRUSTEDREALM.ACME.COM
anzufordern. - Der Client-Browser verwendet das realmübergreifende Kerberos-Ticket aus Schritt 4, um
ein Kerberos-Service-Ticket vom Realm
MYDOMAIN.EXAMPLE.COM
anzufordern. Das Kerberos -Service-Ticket (SPNEGO-Token) beweist die Identität des Benutzers und die Berechtigungen für den Service (Liberty -Server). - Der Client-Browser antwortet dann auf die Abfrage "Authenticate: Negotiate" des Liberty -Servers mit dem SPNEGO-Token, das im vorherigen Schritt im HTTP-Header der Anforderung abgerufen wurde.
- Der Liberty -Server empfängt die Anforderung und überprüft den HTTP-Headermit dem SPNEGO-Token. Dann extrahiert er das Kerberos-Service-Ticket, überprüft das Ticket und ruft die Identität (Principal) des Benutzers ab.
- Nachdem der Liberty -Server die Identität des Benutzers abgerufen hat, validiert er den Benutzer in seiner Benutzerregistry und führt die Berechtigungsprüfungen durch.
- Wenn der Zugriff erteilt wird, sendet der Liberty -Server die Antwort mit
HTTP 200
. Der Liberty -Server enthält auch ein LTPA-Cookie in der Antwort. Dieses LTPA-Cookie wird für nachfolgende Anforderungen verwendet.
Beachten Sie in der Umgebung mit anerkannten Kerberos-Realms, dass die Konfiguration der anerkannten Kerberos-Realms in jedem der Kerberos-KDCs erstellt werden muss. Weitere Informationen zum Konfigurieren anerkannter Kerberos-Realms finden Sie in Ihrem Kerberos-Handbuch für Administratoren und Benutzer.
Informationen zur Unterstützung der SPNEGO-Webauthentifizierung mit einem Browser-Client oder einem Nicht-Browser-Client
- Strukturübergreifende Anerkennung
- Anerkennung von Domänen in derselben Gesamtstruktur
- Anerkennung von Kerberos-Realms
- Anerkennung externer Gesamtstrukturen
- Anerkennung externer Domänen
Die SPNEGO-Authentifizierung kann entweder mit einem SPNEGO-Token oder einem Kerberos-Serviceticket (Kerberos-Token) erfolgen.
Weitere Informationen zur Konfiguration von SPNEGO auf dem Liberty -Server finden Sie unter SPNEGO-Authentifizierung in Liberty konfigurieren.