Wenn Sie die SPNEGO-Webauthentifizierung
(Simple and Protected GSS-API Negotiation) für
WebSphere Application
Server Liberty Profile verwenden, können Sie mit dem Single Sign-on für HTTP-Anforderungen arbeiten. Das SPNEGO-Single-Sign-on
ermöglicht HTTP-Benutzern, nach einmaliger Anmeldung bei einem
Microsoft®-Domänencontroller von ihrem Desktop aus das Single Sign-on für den
Liberty Profile-Server zu nutzen.
Vorbereitende Schritte
Konfigurieren Sie die folgende Software und stellen Sie sicher, dass sie verfügbar ist:
- Microsoft Windows®
Server mit Active-Directory-Domänencontroller und zugehörigem
Kerberos-KDC (Key Distribution Center). Ein Beispielhost für einen solchen Domänencontroller ist in diesem Abschnitt
myAdMachine.example.com.
Der Name des Domänencontrollers ist mydomain.example.com und der Name des Kerberos-Realms ist MYDOMAIN.EXAMPLE.COM, was
dem Namen des Domänencontrollers in Großbuchstaben entspricht.
- Microsoft-Windows®-Domänenmember
(Client) mit Unterstützung für das SPNEGO-Authentifizierungsverfahren gemäß
IETF RFC 2478. Beispiele für einen entsprechenden Client sind ein moderner Browser oder ein
Microsoft-.NET-Client. Die meisten modernen Browser unterstützen
die SPNEGO-Authentifizierung. In diesem Abschnitt ist
myClientMachine.example.com ein Beispielhost für den Client.
- Serverplattform mit einem Liberty Profile-Server, der eine geschützte Ressource in einer Anwendung
enthält. Benutzer im Active Directory müssen in der Lage sein, mit einem nativen Authentifizierungsmechanismus des Liberty Profile-Servers
auf geschützte Ressource des Liberty Profile-Servers zuzugreifen. In diesem Abschnitt ist myLibertyMachine.example.com ein Beispielhost für den Liberty Profile-Server.
Anmerkung: Die Softwarekonfiguration für insgesamt drei erforderliche
Maschinen muss einen aktiven Domänencontroller enthalten, mindestens eine Clientmaschine in der Domäne
und eine Serverplattform mit einem Liberty Profile-Server, der eine geschützte Ressource in einer Anwendung enthält. Die direkte Verwendung von SPNEGO vom
Domänencontroller wird nicht unterstützt.
Anmerkung: Stellen Sie sicher, dass die Uhren des
Clients, des Microsoft-Active-Directory-Servers und des
Liberty Profile-Servers standardmäßig mit einer Abweichung von maximal fünf Minuten synchron sind. Die zulässige Abweichung bei der Synchronisation
ist konfigurierbar.
Anmerkung: Zurzeit werden nur IBM® JDKs
unterstützt. Andere JDKs werden nicht unterstützt.
Informationen zu diesem Vorgang
Ziel dieser Aufgabe ist es, dass Benutzern die Funktionalität des Single-Sign-on vom Microsoft-Windows-Desktop aus
zur Verfügung steht, sodass sie ohne erneute Authentifizierung erfolgreich auf
Liberty Profile-Server-Ressourcen zugreifen können.
Es wird gezeigt, wie ein Liberty Profile-Server konfiguriert werden muss, damit er
die SPNEGO-Webauthentifizierung verwendet, um das SSO für HTTP-Anforderungen zu unterstützen.
Vorgehensweise
- Erstellen Sie im Microsoft-Domänencontroller
(myAdMachine.example.com) einen Kerberos-SPN (Serviceprinzipalnamen) und eine
Chiffrierschlüsseldatei für den Liberty Profile-Server.
- Erstellen Sie einen Benutzeraccount für den Liberty Profile-Server.
Dieser Account wird dem Kerberos-Serviceprinzipalnamen (SPN) zugeordnet. Auf Active-Directory-Maschinen müssen Sie hierfür
in der Regel auswählen, in der Anzeige mit der rechten Maustaste auf Benutzer klicken und
dann auswählen. In diesem Abschnitt wird davon ausgegangen, dass
ein Benutzer myLibertyMachine_http mit dem Kennwort security erstellt wurde.
- Führen Sie den Microsoft-Befehl setspn aus, um den
Benutzeraccount einem Kerberos-SPN zuzuordnen. Dieser Benutzeraccount stellt den
Liberty Profile-Server gegenüber dem KDC als einen Kerberos-Service dar. Nachfolgend sehen Sie ein Beispiel für einen setspn-Befehl:
C:\> setspn -a HTTP/myLibertyMachine.example.com myLibertyMachine_http
Der Dienstprinzipalname für CN=myLibertyMachine_http,CN=Users,DC=MYDOMAIN,DC=EXAMPLE,DC=COM wird registriert.
HTTP/myLibertyMachine.example.com
Aktualisiertes Objekt
Anmerkung: Wenn Ihre Version des Microsoft-Befehls setspn
die Option -S unterstützt, müssen Sie anstelle von
-A die Option -S verwenden.
- Erstellen Sie mit dem Microsoft-Tool ktpass die Kerberos-Chiffrierschlüsseldatei.
Diese Datei hat standardmäßig den Namen krb5.keytab.
Nachfolgend sehen Sie ein Beispiel für einen ktpass-Befehl:
C:\> ktpass -out krb5.keytab -princ HTTP/myLibertyMachine.example.com@MYDOMAIN.EXAMPLE.COM -mapUser myLibertyMachine_http -mapOp set -pass security -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL
Bestimmen des Domänencontrollers: myAdMachine.MYDOMAIN.EXAMPLE.COM
Verwenden der Methode zum Festlegen von Legacy-Kennwörtern
HTTP/myLibertyMachine.example.com wurde myLibertyMachine_http zugeordnet.
Schlüssel wurde erstellt.
Ausgabeschlüsseltabelle für krb5.keytab:
Schlüsseltabellenversion: 0x502
Schlüsselgröße 93 HTTP/myLibertyMachine.example.com@MYDOMAIN.EXAMPLE.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x17 (RC4-HMAC) Schlüssellänge 16 (0x148d643db283327d3f3d44547da8cade)
Stellen Sie mit einem der folgenden Befehle sicher, dass in der
Microsoft-Gesamtstruktur kein SPN-Duplikat vorhanden ist:
- Wenn Ihre Version des Microsoft-Befehls setspn
die Option -X für die Suche nach einem SPN-Duplikat unterstützt, verwenden Sie
setspn -X.
C:\>setspn -X HTTP/myLibertyMachine.example.com
Eintrag 0 wird verarbeitet.
0 Gruppen mit doppelten SPNs gefunden.
- Sie können auch den Microsoft-Befehl ldif verwenden.
Das folgende Beispiel zeigt, dass ein Eintrag zurückgegeben wurde und somit keine SPN-Duplikate vorhanden sind.
C:\>ldifde -f check_SPN.txt -t 3268 -d "" -l servicePrincipalName -r "
(servicePrincipalName=HTTP/myLibertyMachine.example.com)" -p subtree
Verbindung zu "myAdMachine.MYDOMAIN.EXAMPLE.COM" wird hergestellt.
Anmelden als aktueller Benutzer unter Verwendung von SSPI
Das Verzeichnis wird in die Datei check_SPN.txt exportiert.
Es wird nach Einträgen gesucht...
Die Einträge werden geschrieben.
1 Einträge wurden exportiert.
Informationen zum Erstellen von SPN und Chiffrierschlüsseldateien für andere
KDC-Systeme finden Sie
unter
erberos-Service-Principal-Namen und eine Chiffrierschlüsseldatei erstellen.
- Aktivieren Sie auf der Maschine mit dem Liberty Profile-Server (myLibertyMachine.example.com)
den Kerberos-Chiffrierschlüssel, die Konfigurationsdateien und die SPNEGO-Webauthentifizierung.
- Kopieren Sie die Kerberos-Chiffrierschlüsseldatei vom Domänencontroller auf die Maschine mit dem
Liberty Profile-Server. Diese Datei hat standardmäßig den Namen
krb5.keytab. Die Standardposition der Datei ist je nach Plattform verschieden. Die Datei befindet sich jedoch in demselben
Verzeichnis wie die Kerberos-Konfigurationsdatei. Die Standardpositionen für die verschiedenen Plattformen sind im nächsten Schritt angegeben.
- Erstellen Sie eine Kerberos-Konfigurationsdatei.
Die Kerberos-Konfigurationsdatei enthält Clientkonfigurationsinformationen, zu denen auch die
Position der KDCs für die interessierenden Realms, die Standardwerte für das aktuelle
Kerberos-Realm und die Zuordnung von Hostnamen zu Kerberos-Realms gehören. Für Liberty Profile-Server müssen Sie diese Datei manuell erstellen.
Nachfolgend sehen Sie ein Beispiel für eine Kerberos-Konfigurationsdatei für
die Plattformen AIX, z/OS, HP-UX oder Solaris (ausgehend von der Standardposition
für Chiffrierschlüssel):
[libdefaults]
default_realm = MYDOMAIN.EXAMPLE.COM
default_keytab_name = FILE:/etc/krb5/krb5.keytab
default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac
forwardable = true
renewable = true
noaddresses = true
clockskew = 300
udp_preference_limit = 1
[realms]
MYDOMAIN.EXAMPLE.COM = {
kdc = myAdMachine.example.com:88
default_domain = example.com
}
[domain_realm]
.example.com = MYDOMAIN.EXAMPLE.COM
Anmerkung: Realmnamen werden normalerweise in Großbuchstaben angegeben. Wenn Sie Microsoft Active Directory
verwenden, müssen Realmnamen großgeschrieben sein.
Anmerkung: Nicht alle verfügbaren
KDC-Lösungen unterstützen alle Verschlüsselungstypen. Vergewissern Sie sich vor Auswahl eines Verschlüsselungstyps,
dass das KDC den gewünschten Typ unterstützt. Informieren Sie sich anhand des
Kerberos-Handbuchs für Administratoren und Benutzer.
Stellen Sie sicher, dass Sie einen einheitlichen Verschlüsselungstyp für die
Kerberos-Konfigurationsdatei, die Kerberos-Chiffrierschlüsseldatei, den Kerberos-SPN und den Kerberos-Client
verwenden. Wenn der Kerberos-Client beispielsweise den
Verschlüsselungstyp RC4-HMAC verwendet, muss der Zielserver auch den Verschlüsselungstyp
RC4-HMAC unterstützen und in der
Kerberos-Konfigurationsdatei muss in den Parametern
default_tgt_enctypes und default_tkt_enctypes RC4-HMAC zuerst aufgelistet sein.
Zusätzliche Informationen und weitere Anforderungen an den Inhalt dieser Datei finden Sie unter
Kerberos-Konfigurationsdatei erstellen.
- Überprüfen Sie die Kerberos-Konfigurationsdatei und -Chiffrierschlüsseldatei.
Nach Ausführung des Befehls kinit können Sie den Befehl klist verwenden, um das
Kerberos-Ticket aufzulisten. Wenn Sie das Kerberos-Ticket abrufen können, sind der
Kerberos-Chiffrierschlüssel und die Kerberos-Konfiguration gültig.
- Konfigurieren und aktivieren Sie die SPNEGO-Webauthentifizierung für den
Liberty Profile-Server.
Sie können die SPNEGO-Webauthentifizierung durch das Aktivieren des Features spnego-1.0 im Liberty-Profil aktivieren.
- Fügen Sie das Feature spnego-1.0 zur Datei server.xml hinzu.
<featureManager>
<feature>spnego-1.0</feature>
<feature>appSecurity-2.0</feature>
...
</featuremanager>
Durch das Hinzufügen des Features spnego-1.0 wird automatisch eine bestimmte
Mindestkonfiguration durchgesetzt. Sie müssen kein Element
<spnego> in der Datei server.xml angeben.
Ohne Angabe eines <spnego>-Elements ist die folgende Konfiguration implizit.
<spnego
canonicalHostName="true"
disableFailOverToAppAuthType="true"
trimKerberosRealmNameFromPrincipal="true"
includeClientGSSCredentialInSubject="true" />
Anmerkung: Die Laufzeit bildet den Standard-SPN im folgenden
Format:
"HTTP/" + java.net.InetAddress.getLocalHost().getCanonicalHostName();
Wenn der
Standard-SPN nicht zum Inhalt der Datei krb5.keytab passt, müssen Sie das Element
servicePrincipalNames angeben.
Beispiel:
<spnego id="mySpnego" servicePrincipalNames="HTTP/myLibertyMachine.example.com"/>
Anmerkung: Wenn das Feature
spnego-1.0 aktiviert und das Element <spnego> nicht angegeben oder nicht mit einem
Attribut authFilterRef konfiguriert ist, verwenden alle Anforderungen nach Zugriff auf geschützte Ressourcen
die SPNEGO-Authentifizierung.
Informationen zum Konfigurieren des
Authentifizierungsfilters finden Sie unter

Authentifizierungsfilter.
Anmerkung: Wenn keine Werte für das Attribut
krb5Config oder krb5Keytab angegeben sind, wird erwartet, dass sich alle betreffenden Dateien
an ihrer jeweiligen Standardposition befinden. Die Standardposition für die Kerberos-Konfigurationsdatei und -Chiffrierschlüsseldatei
auf verschiedenen Plattformen ist weiter oben in diesem Abschnitt angegeben.
- Bei Bedarf können Sie zusätzliche Konfigurationsoptionen angeben.
Das Liberty-Profil unterstützt viele allgemeine SPNEGO-Szenarien und -Konfigurationen.
Sie können beispielsweise HTTP-Anforderungen filtern, sodass die SPNEGO-Authentifizierung nur für bestimmte Anforderungen,
Webanwendungen, Hosts oder Benutzeragenten erforderlich ist.
Sie können die Kerberos-Konfigurationsdatei und -Chiffrierschlüsseldatei auch von der jeweiligen Standardposition an eine andere
Position verschieben. Im folgenden Beispiel sehen Sie eine Konfiguration, die die
Standardeinstellungen für <spnego> ändert:
<server>
<featureManager>
<feature>spnego-1.0</feature>
<feature>appSecurity-2.0</feature>
...
</featureManager>
...
<authFilter id="myAuthFilter">
<host id="myHost" name="example.com" matchType="contains" />
<webApp id="myWebApp" name="protectedApp" matchType="equals" />
</authFilter>
<spnego id="mySpnego"
includeClientGSSCredentialInSubject="false"
krb5Config="${server.config.dir}/resources/security/kerberos/krb5.conf"
krb5Keytab="${server.config.dir}/resources/security/kerberos/krb5.keytab"
servicePrincipalNames="HTTP/myLibertyMachine.example.com"
authFilterRef="myAuthFilter" />
...
</server>
Bei dieser Konfiguration wird die SPNEGO-Authentifizierung für alle Anforderungen verwendet, die
mit dem Hostnamen example.com für Ressourcen in der Webanwendung
protectedApp empfangen werden.
Bei erfolgreicher Authentifizierung werden die GSS-Berechtigungsnachweise des Clients nicht zum Benutzersubjekt
hinzugefügt. Am Ende werden die Kerberos-Konfigurationsdatei und -Chiffrierschlüsseldatei, die vom Server verwendet werden sollen,
nicht an ihre jeweilige Standardposition gestellt, sondern an bestimmte Positionen im Serverkonfigurationsverzeichnis.
Weitere Konfigurationsoptionen
finden Sie unter 
SPNEGO (Simple and Protected GSS-API
Negotiation).
Informationen zur Zuordnung von
Kerberos-Prinzipalnamen zu WebSphere-Benutzerregistry-IDs finden Sie
unter
Mapping of a client Kerberos principal name to the WebSphere user registry ID.
Für den
seltenen Fall, dass Sie Kerberos-Prinzipalnamen für die Autorisierung verwenden möchten, lesen
Sie die Informationen unter

Kerberos-Principal-Namen für Berechtigung mit SPNEGO-Authentifizierung verwenden. Diese Schritte sollten Benutzer,
die sich gegen die Standardzuordnung oder die Zuordnung des angepassten JAAS-Anmeldemoduls entscheiden, nur ausführen,
wenn dies absolut notwendig ist.
- Konfigurieren Sie die Clientanwendung auf dem Clientanwendungssystem (myClientMachine.example.com).
Die folgenden Schritte müssen nur auf der Clientmaschine ausgeführt werden. Wenn Sie auf der
Active-Directory- oder Profile-Server-Maschine einen Browser starten, funktioniert die Ausführung dieser Schritte nicht.
Die folgenden Schritte sind für Benutzer bestimmt, die mit einem Browser auf SPNEGO-geschützte Ressourcen zugreifen. Sie müssen einen Browser installiert haben, der
die SPNEGO-Authentifizierung unterstützt.
Microsoft Internet
Explorer:
- Melden Sie sich vom Desktop aus bei der Windows-Active-Directory-Domäne
an.
- Klicken Sie im Fenster des Internet Explorer auf
. Klicken Sie in dem daraufhin angezeigten Fenster auf das
Register Sicherheit.
- Wählen Sie das Symbol Lokales Intranet aus und klicken Sie auf Sites.
- Wenn Sie Internet Explorer bis Version 9 verwenden, fahren Sie mit dem nächsten Schritt fort. Wenn Sie Internet Explorer ab Version 10
verwenden, klicken Sie im Fenster "Lokales Intranet" auf Erweitert.
- Tragen Sie im Fenster "Lokales Intranet" im Feld Diese Website
zur Zone hinzufügen die Webadresse des Hosts ein, sodass das Single Sign-on (SSO) für die Liste der im Feld "Websites" aufgeführten
Websites aktiviert werden kann. Sie erhalten diese Angaben von den bei Ihnen zuständigen Mitarbeitern für
Siteinformationen. Schließen Sie das zweite Fenster "Lokales Intranet" und klicken Sie auf
OK, um diesen Schritt abzuschließen. Schließen Sie dann das verbleibende Fenster "Lokales Intranet".
- Klicken Sie im Fenster Internetoptionen auf das Register Erweitert und blättern Sie zu den
Einstellungen unter "Sicherheit" vor. Vergewissern Sie sich, dass das Feld Integrierte
Windows®-Authentifizierung aktivieren ausgewählt ist.
- Klicken Sie auf OK. Starten Sie Microsoft Internet Explorer neu, um diese Konfiguration
zu aktivieren.
Mozilla Firefox:
- Melden Sie sich vom Desktop aus bei der Windows-Active-Directory-Domäne
an.
- Geben Sie im Adressfeld von Firefox about:config ein.
- Geben Sie im Filter-/Suchfeld network.n ein.
- Klicken Sie doppelt auf network.negotiate-auth.trusted-uris.
Diese Vorgabe listet die Sites auf, die berechtigt sind, an der SPNEGO-Authentifizierung mit dem Browser
teilzunehmen. Listen Sie anerkannte Domänen oder URLs mit jeweils einem Komma als Trennzeichen auf.
Anmerkung: Sie müssen den Wert für
network.negotiate-auth.trusted-uris definieren.
- Wenn die implementierte SPNEGO-Lösung das erweiterte Kerberos-Feature für die Delegierung von Berechtigungsnachweisen
(Credential Delegation) verwendet, klicken Sie doppelt auf network.negotiate-auth.delegation-uris.
Diese Vorgabe listet die Sites auf, für die der Browser die Benutzerautorisierung an den Server delegieren kann. Listen Sie anerkannte Domänen oder URLs mit jeweils einem Komma als Trennzeichen auf.
- Klicken Sie auf OK. Die Konfiguration bildet die Aktualisierungen ab.
- Starten Sie Ihren Firefox-Browser neu, um diese Konfiguration zu aktivieren.
Anmerkung: Der Benutzer muss beim Domänencontroller angemeldet sein, damit SPNEGO funktioniert. Für die oben beschriebenen Beispielmaschinen muss sich ein Benutzer
beim Domänencontroller unter MYDOMAIN.EXAMPLE.COM\username anmelden, damit die
SPNEGO-Authentifizierung über den Browser funktioniert.
Anmerkung: Wenn Sie mehrfach aufgefordert werden, eine Benutzer-ID und ein Kennwort einzugeben, stellen Sie sicher, dass Sie für Ihren Client-Browser die SPNEGO-Unterstützung gemäß den obigen Anweisungen aktiviert haben. Vergewissern Sie sich auch,
dass das Attribut disableFailOverToAppAuthType der
<spnego>-Konfiguration auf false gesetzt ist.
Ergebnisse
Ihr Internet-Browser ist jetzt ordnungsgemäß für die SPNEGO-Authentifizierung konfiguriert. Sie können in Liberty Profile-Servern implementierte
Anwendungen mit geschützten Ressourcen verwenden, ohne nach einer Benutzer-ID oder einem Kennwort gefragt zu werden.
Überprüfen Sie, ob SPNEGO funktioniert. Melden
Sie sich dazu beim Domänencontroller an und greifen Sie auf eine geschützte Ressource im Liberty Profile-Server zu.
Da Sie beim Domänencontroller angemeldet sind, werden Sie nicht zur Eingabe von Berechtigungsnachweisen aufgefordert. Melden Sie sich nicht beim
Domänencontroller an und versuchen, auf eine geschützte Ressource zuzugreifen, werden Sie aufgefordert, Berechtigungsnachweise einzugeben.