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.

Neben den Sicherheitslaufzeitservices von WebSphere Application Server sind einige externe Komponenten erforderlich, um den Betrieb von SPNEGO zu ermöglichen. Zu den externen Komponenten gehören folgende:
  • Für Windows-PlattformenMicrosoft 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.

Abbildung 1. SPNEGO-Webauthentifizierung in einem einzigen Kerberos-Realm

Die SPNEGO-Webauthentifizierung wird in einem einzigen Kerberos-Realm unterstützt. Der Handshake-Prozess für das Challenge/Response-Verfahren wird angezeigt.

In der obigen Abbildung kommt es zu folgenden Ereignissen:

  1. Zu Beginn meldet sich der Benutzer über die Workstation am Microsoft-Domänencontroller MYDOMAIN.EXAMPLE.COM an.
  2. 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.
  3. Die SPNEGO-Authentifizierung im Liberty -Server beantwortet den Client-Browser mit einem HTTP 401 -Anforderungsheader, der den Status Authenticate: Negotiate enthält.
  4. 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 gibt TGS 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).
  5. 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.
  6. 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.
  7. 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.
  8. 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.
Hinweis: Andere Clients (z. B. Web-Services, .NET und J2EE), die SPNEGO unterstützen, müssen den zuvor beschriebenen Handshake-Prozess für Challenge/Response nicht ausführen. Solche Clients können ein TGT (Ticket-Granting-Ticket) und ein Kerberos-Service-Ticket für den Zielserver anfordern, ein SPNEGO-Token erstellen, dieses Token in den HTTP-Header einfügen und dann den normalen Prozess für die Erstellung einer HTTP-Anforderung durchlaufen.

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.

Abbildung 2. SPNEGO-Webauthentifizierung in einem anerkannten Kerberos-Realm

Die SPNEGO-Webauthentifizierung wird auch in einem anerkannten Kerberos-Realm unterstützt. Der Handshake-Prozess für das Challenge/Response-Verfahren wird angezeigt.

In der obigen Abbildung kommt es zu folgenden Ereignissen:

  1. Der Benutzer meldet sich beim Microsoft-Domänencontroller TRUSTEDREALM.ACME.COMan.
  2. 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.COMgehostet wird.
  3. Der Liberty -Server beantwortet den Client-Browser mit einem HTTP 401-Abfrage-Header, der den Status Authenticate: Negotiate enthält.
  4. 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ür MYDOMAIN.EXAMPLE.COM vom Realm TRUSTEDREALM.ACME.COM anzufordern.
  5. 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).
  6. 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.
  7. 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.
  8. 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.
  9. 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.
Anmerkung: Es ist keine Änderung am Liberty -Server erforderlich, um mehr anerkannte Realms zu unterstützen. Eine Vertrauensbeziehung zwischen den notwendigen Active Directory-Realms ist die einzige Voraussetzung dafür, dass SPNEGO mit vertrauenswürdigen Realms funktioniert.

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

Folgende Szenarien werden unterstützt:
  • Strukturübergreifende Anerkennung
  • Anerkennung von Domänen in derselben Gesamtstruktur
  • Anerkennung von Kerberos-Realms
Die folgenden Szenarien werden nicht unterstützt:
  • 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.