Single Sign-on für HTTP-Anforderungen mit SPNEGO-Webauthentifizierung

Sie können HTTP-Anforderungen nach geschützten Ressourcen in WebSphere Application Server sicher aushandeln und authentifizieren, indem Sie das SPNEGO-Verfahren (Simple and Protected GSS-API Negotiation) als Webauthentifizierungsservice für WebSphere Application Server verwenden.

In den folgenden Abschnitten ist die SPNEGO-Webauthentifizierung ausführlicher beschrieben:

Was ist SPNEGO?

SPNEGO ist eine Standardspezifikation, die im IETF RFC 2478 - The Simple and Protected GSS-API Negotiation Mechanism definiert ist.

Wenn die Sicherheit des Liberty-Servers und die SPNEGO-Webauthentifizierung aktiviert sind, wird SPNEGO bei der Verarbeitung der ersten eingehenden HTTP-Anforderung initialisiert. 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.

Für den Betrieb von SPNEGO sind neben den Sicherheitslaufzeitservices von WebSphere Application Server einige externe Komponenten erforderlich. Zu diesen 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 wie in IETF RFC 2478 definiert unterstützt. Microsoft Internet Explorer und Mozilla Firefox sind Beispiele für Browser. 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 haben die Aufgabe, das SPNEGO-Token für die SPNEGO-Webauthentifizierung zu generieren. Die Benutzeridentität in der Sicherheitsregistry von WebSphere Application Server muss mit der Identität übereinstimmen, die die SPNEGO-Webauthentifizierung abruft. Eine vollständige Übereinstimmung wird festgestellt, wenn der Microsoft Windows Active Directory-Server der von WebSphere Application Server verwendete LDAP-Server ist. Zur Unterstützung der benutzerdefinierten Zuordnung der Identität von Active Directory zur Sicherheitsregistry von WebSphere Application Server ist ein angepasstes Anmeldemodul als Plug-in verfügbar.

WebSphere Application Server wertet die Identität anhand seiner Sicherheitsregistry aus. 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 nach weiteren geschützte Ressourcen in WebSphere Application Server, die von demselben Benutzer stammen, verwenden das zuvor erstellte LTPA-Sicherheitstoken, um wiederholte Anmeldeaufforderungen zu vermeiden.

SPNEGO-Webauthentifizierung in einem einzelnen Kerberos-Realm

Die SPNEGO-Webauthentifizierung wird in einem einzelnen Kerberos-Realm (Domäne) unterstützt. Der Challenge/Response-Handshake-Prozess ist in der folgenden Abbildung dargestellt:

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

Die SPNEGO-Webauthentifizierung wird in einem einzelnen Kerberos-Realm unterstützt. Dargestellt ist der Challenge/Response-Handshake-Prozess.

In der obigen Abbildung kommt es zu folgenden Ereignissen:

  1. Zu Beginn meldet sich der Benutzer über die Workstation beim Microsoft-Domänencontroller MYDOMAIN.EXAMPLE.COM an.
  2. Anschließend versucht der Benutzer, auf die Webanwendung zuzugreifen. Der Benutzer fordert eine geschützte Webressource mithilfe eines Client-Browsers an, der eine Anforderung HTTP GET an den Liberty-Server sendet.
  3. Die SPNEGO-Authentifizierung im Liberty-Server antwortet dem Client-Browser mit einem Anforderungsheader HTTP 401, der den Status Authenticate: Negotiate enthält.
  4. Der Client-Browser erkennt den Anforderungsheader, weil er für die Unterstützung der integrierten Windows-Authentifizierung konfiguriert ist. Der Client analysiert die angeforderte URL, um den Hostnamen zu ermitteln. Er verwendet den Hostnamen, um den Namen des Kerberos-Ziel-Service-Principals HTTP/myLibertyMachine.example.com zu formen, damit vom Service für Kerberos-Tickets (TGS) im Microsoft-Kerberos-KDC (TGS_REQ) ein Kerberos-Service-Ticket angefordert werden kann. Der TGS (Ticket Granting Service) stellt dann ein Kerberos-Service-Ticket (TGS_REP) für den Client aus. Das Kerberos-Service-Ticket (SPNEGO-Token) gibt die Identität des Benutzers und seine Berechtigungen für den Service (Liberty-Server) an.
  5. Der Client-Browser antwortet auf die Anforderung "Authenticate: Negotiate" des Liberty-Servers mit dem SPNEGO-Token, das im vorherigen Schritt im HTTP-Anforderungsheader abgerufen wurde.
  6. Die SPNEGO-Authentifizierung im Liberty-Server sieht den HTTP-Header mit dem SPNEGO-Token und ruft die Identität (Principal) des Benutzers ab.
  7. Wenn der Liberty-Server die Identität des Benutzers abgerufen hat, überprüft er den Benutzer anhand seiner Benutzerregistry und führt die Berechtigungsprüfungen durch.
  8. Wenn der Zugriff bewilligt wird, sendet der Liberty-Server die Antwort mit HTTP 200. In die Antwort nimmt der Liberty-Server auch ein LTPA-Cookie auf. Dieses LTPA-Cookie wird für nachfolgende Anforderungen verwendet.
Anmerkung: Andere Clients (z. B. Web-Service-Clients, .NET-Clients und J2EE-Clients), die SPNEGO unterstützen, müssen nicht dem zuvor beschriebenen Challenge/Response-Handshake-Prozess folgen. 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 Challenge/Response-Handshake-Prozess 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. Dargestellt ist der Challenge/Response-Handshake-Prozess.

In der obigen Abbildung kommt es zu folgenden Ereignissen:

  1. Der Benutzer meldet sich beim Microsoft-Domänencontroller TRUSTEDREALM.ACME.COM an.
  2. In einem Client-Browser setzt der Benutzer eine Anforderung nach einer geschützten Webressource ab, die von einem Liberty-Server im ursprünglichen Microsoft-Domänencontroller MYDOMAIN.EXAMPLE.COM bereitgestellt wird.
  3. Der Liberty-Server antwortet dem Client-Browser mit einem Anforderungsheader HTTP 401, der den Status Authenticate: Negotiate enthält.
  4. Der Client-Browser ist für die Unterstützung der integrierten Windows-Authentifizierung konfiguriert. Er analysiert die URL unter Verwendung des Hostnamens der Workstation, auf der der Liberty-Server ausgeführt wird. 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) gibt die Identität des Benutzers und seine Berechtigungen für den Service (Liberty-Server) an.
  6. Der Client-Browser antwortet auf die Anforderung "Authenticate: Negotiate" des Liberty-Servers mit dem SPNEGO-Token, das im vorherigen Schritt im HTTP-Anforderungsheader abgerufen wurde.
  7. Der Liberty-Server empfängt die Anforderung und prüft den HTTP-Header mit dem SPNEGO-Token. Dann extrahiert er das Kerberos-Service-Ticket, überprüft das Ticket und ruft die Identität (Principal) des Benutzers ab.
  8. Wenn der Liberty-Server die Identität des Benutzers abgerufen hat, überprüft er den Benutzer anhand seiner Benutzerregistry und führt die Berechtigungsprüfungen durch.
  9. Wenn der Zugriff bewilligt wird, sendet der Liberty-Server die Antwort mit HTTP 200. In die Antwort nimmt der Liberty-Server auch ein LTPA-Cookie auf. Dieses LTPA-Cookie wird für nachfolgende Anforderungen verwendet.
Anmerkung: Zur Unterstützung weiterer anerkannter Realms ist keine Modifikation des Liberty-Servers erforderlich. 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 Einrichten 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:
  • Gesamtstrukturübergreifende Vertrauensbeziehung
  • Domäne mit Vertrauensstellung innerhalb einer Gesamtstruktur
  • Vertrauensbeziehung im Kerberos-Realm
Folgende Szenarien werden nicht unterstützt:
  • Vertrauensbeziehungen außerhalb der Gesamtstruktur
  • Vertrauensbeziehungen außerhalb der Domäne

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.