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.

Anmerkung: In WebSphere Application Server Version 6.1 wurde ein TAI eingeführt, der SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) nutzt, um HTTP-Anforderungen für geschützte Ressourcen sicher auszuhandeln und zu authentifizieren. Diese Funktion wird ab WebSphere Application Server Version 7.0 nicht weiter unterstützt. Stattdessen wird jetzt die SPNEGO-Webauthentifizierung genutzt, die folgende Verbesserungen bietet:
  • Ü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?

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.

Neben den Sicherheitslaufzeitservices von WebSphere Application Server sind einige externe Komponenten erforderlich, um SPNEGO zu aktivieren. Zu den externen Komponenten gehören folgende:
  • [Windows]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.

[AIX Solaris HP-UX Linux Windows][IBM i]Weitere Informationen zu diesem angepassten Anmeldemodulfinden Sie im Artikel [AIX Solaris HP-UX Linux Windows][IBM i]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:

Abbildung 1. SPNEGO-Webauthentifizierung und Elemente der SicherheitskonfigurationDer Webadministrator hat Zugriff auf die folgenden SPNEGO-Sicherheitskomponenten und die zugehörigen Konfigurationsdaten: Webauthentifizierungsmodul, SPNEGO Trust Association Interceptor, JGSS und SPNEGO-Sicherheitsprovider, Kerberos-Konfiguration und Kerberos-Chiffrierschlüsseldateien, SPNEGO-TAI-Konfigurationseigenschaften und JVM-Systemeigenschaften.

Vorteile der SPNEGO-Webauthentifizierung

Im Folgenden sind einige Vorteile des Einsatzes von Kerberos als Authentifizierungsverfahren für WebSphere Application Server beschrieben:

  • [Windows]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.

Abbildung 2. SPNEGO-Webauthentifizierung in einem einzigen Kerberos-RealmDie SPNEGO-Webauthentifizierung wird in einem einzelnen Kerberos-Realm unterstützt. Der Handshake-Prozess mit Anforderung und Antwort wird gezeigt.

In der vorherigen Abbildung werden die folgenden Ereignisse gezeigt:

  1. Der Client sendet eine HTTP/Post/Get/Web-Service-Anforderung an WebSphere Application Server.
  2. WebSphere Application Server gibt HTTP 401 Authenticate/Negotiate zurück.
  3. Der Client ruft ein Ticket-Granting-Ticket (TGT) ab.
  4. Der Client fordert ein Serviceticket (TGS_REQ) an.
  5. Der Client ruft ein Serviceticket ab (TGS_REP).
  6. Der Client sendet HTTP/Post/Get/Web-Service und ein SPNEGO-Berechtigungstoken an WebSphere Application Server.
  7. 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.
  8. WebSphere Application Server überprüft die Benutzer-ID in der WebSphere-Benutzerregistry und erstellt ein LTPA-Token.
  9. WebSphere Application Server gibt HTTP 200, Inhalt und das LTPA-Token an den Client zurück.
Anmerkung: Andere Clients (z. B. Web-Services, .NET und J2EE), die SPNEGO unterstützen, müssen dem zuvor beschriebenen Handshake-Prozess für den Anforderung/Antwort-Austausch nicht folgen. Diese Clients können ein Ticket-Granting-Ticket (TGT) und ein Kerberos-Serviceticket für den Zielserver abrufen, ein SPNEGO-Token erstellen, das Token in den HTTP-Header einfügen und dann ganz normal eine HTTP-Anforderung erstellen.

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.

Abbildung 3. SPNEGO-Webauthentifizierung in einem anerkannten Kerberos-RealmDie SPNEGO-Webauthentifizierung wird auch in einem anerkannten Kerberos-Realm unterstützt. Der Handshake-Prozess mit Anforderung/Antwort-Austausch wird gezeigt.

In der vorherigen Abbildung werden die folgenden Ereignisse gezeigt:

  1. Der Client sendet eine HTTP/Post/Get/Web-Service-Anforderung an WebSphere Application Server.
  2. WebSphere Application Server gibt HTTP 401 Authenticate/Negotiate zurück.
  3. Der Client ruft ein Ticket-Granting-Ticket (TGT) ab.
  4. Der Clientanforderung fordert ein realmübergreifendes Ticket (TGS_REQ) für REALM2 vom KDC von REALM1 an.
  5. Der Client verwendet das realmübergreifende Ticket aus Schritt 4, um ein Serviceticket vom KDC von REALM2 anzufordern.
  6. Der Client sendet HTTP/Post/Get/Web-Service und ein SPNEGO-Berechtigungstoken an WebSphere Application Server.
  7. 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.
  8. WebSphere Application Server überprüft die Benutzer-ID in der WebSphere-Benutzerregistry und erstellt ein LTPA-Token.
  9. 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.

    [AIX Solaris HP-UX Linux Windows][IBM i]Weitere Informationen finden Sie im Artikel [AIX Solaris HP-UX Linux Windows][IBM i]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

Die folgenden Szenarien werden unterstützt:
  • Anerkennung von Domänen in derselben Gesamtstruktur
  • Anerkennung externer Domänen, die direkt zwischen Domänen in verschiedenen Gesamtstrukturen erfolgt.
  • Anerkennung von Kerberos-Realms
Die folgenden Szenarien werden nicht unterstützt:
  • Strukturübergreifende Anerkennung
  • Anerkennung externer Gesamtstrukturen

Unterstützungsinformationen für die SPNEGO-Webauthentifizierung mit einem Browserclient

Die folgenden 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

SPNEGO als Authentifizierungsverfahren für WebSphere Application Server konfigurieren

Bevor Sie die SPNEGO-Webauthentifizierung in der Administrationskonsole oder mit wsadmin-Befehlen konfigurieren, müssen Sie die im Artikel Single Sign-On für HTTP-Anforderungen über die SPNEGO-Webauthentifizierung erstellen beschriebenen Schritte ausführen, um die SPNEGO-Webauthentifizierung für WebSphere Application Server zu konfigurieren.
Anmerkung: Die SPNEGO-Webauthentifizierung muss auf Serverseite vom Systemadministrator durchgeführt werden. Die Kerberos-Chiffrierschlüsseldatei muss geschützt werden.

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=csec_SPNEGO_explain
Dateiname:csec_SPNEGO_explain.html