Wenn Sie die SPNEGO-Webauthentifizierung (Simple and Protected GSS-API Negotiation Mechanism) für WebSphere Application Server Liberty verwenden, können Sie Single Sign-on für HTTP-Anforderungen verwenden. Mit SPNEGO-Single-Sign-on können HTTP-Benutzer Single Sign-on für den Liberty-Server nach einmaliger Anmeldung bei einem Microsoft®-Domänencontroller über ihren Desktop verwenden.
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-Server, dessen Anwendung eine geschützte Ressource
enthält. Benutzer in Active Directory müssen in der Lage sein, mit einem nativen Authentifizierungsmechanismus des Liberty-Servers
auf geschützte Ressourcen des Liberty-Servers zuzugreifen. In diesem Abschnitt ist myLibertyMachine.example.com ein Beispielhost für den Liberty-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-Server, dessen Anwendung eine geschützte Ressource 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-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 SSO-Funktion vom Microsoft Windows-Desktop aus zur Verfügung steht, sodass sie ohne erneute Authentifizierung erfolgreich auf Liberty-Server-Ressourcen zugreifen können.
Es wird gezeigt, wie ein Liberty-Server konfiguriert werden muss, damit er die SPNEGO-Webauthentifizierung verwendet, um das SSO für HTTP-Anforderungen zu unterstützen.
Vorgehensweise
- rstellen Sie im Microsoft-Domänencontroller (myAdMachine.example.com) einen Kerberos-SPN (Service-Principal-Namen) und eine Chiffrierschlüsseldatei für den Liberty-Server:
- Erstellen Sie einen Benutzeraccount für den Liberty-Server. Dieser Account wird für die Zuordnung zum Kerberos-Service-Principal-Namen (SPN) verwendet.
Auf Active Directory-Maschinen müssen Sie zum Erstellen dieses Accounts
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-Server gegenüber dem KDC als einen Kerberos-Service dar. Im Folgenden sehen Sie ein Beispiel für den Befehl setspn:
C:\> setspn -a HTTP/myLibertyMachine.example.com myLibertyMachine_http
Der Service-Principal-Name 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
ktpass-Tool die Kerberos-Chiffrierschlüsseldatei. Diese Datei hat standardmäßig den Namen krb5.keytab.
Im Folgenden sehen Sie ein Beispiel für den Befehl ktpass:
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-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-Server. Diese Datei hat standardmäßig den Namen
krb5.keytab. Die Standardposition der Datei unterscheidet sich je nach Plattform. 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 Clientkonfigurationsdaten. Zu diesen Daten gehören die Positionen
der KDCs für die relevanten Realms, die Standardwerte für den aktuellen Kerberos-Realm und die Zuordnungen
von Hostnamen zu Kerberos-Realms. Für Liberty-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 in Großbuchstaben
angegeben werden.
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-Server.
Sie können die SPNEGO-Webauthentifizierung durch das Aktivieren des Features spnego-1.0 in Liberty aktivieren.
- Fügen Sie das Feature spnego-1.0 der 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
<spnego>-Element 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 dem in der Datei krb5.keytab angegebenen Namen entspricht, 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 für 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 Beispiel angegeben.
- Optional: Bei Bedarf können Sie zusätzliche Konfigurationsoptionen angeben. Liberty 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" />
</spnego>
...
</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 dem 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-Principalnamen 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-Principalnamen für die Berechtigung verwenden möchten, lesen
Sie die Informationen unter
Kerberos-Principal-Namen für Berechtigung mit SPNEGO-Authentifizierung verwenden. Diese Schritte sollten nur bei Bedarf und ausschließlich von Benutzern,
die sich gegen die Standardzuordnung oder die Zuordnung des angepassten JAAS-Anmeldemoduls entscheiden, ausgeführt werden.
- Konfigurieren Sie die Clientanwendung auf dem Clientanwendungssystem (myClientMachine.example.com).
Die folgenden Schritte müssen nur auf der Clientmaschine ausgeführt werden. Diese Schritte können nicht ausgeführt werden, wenn ein Browser auf einer Active Directory- oder Liberty-Server-Maschine gestartet wird.
Die folgenden Schritte sind für Benutzer bestimmt, die mit einem Browser auf SPNEGO-geschützte Ressourcen zugreifen. Es muss ein Browser installiert sein, 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 von 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 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 Benutzerberechtigung 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 übernimmt die Aktualisierungen.
- 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-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-Server zu. Da Sie beim Domänencontroller angemeldet sind, werden Sie nicht zur Eingabe von Berechtigungsnachweisen aufgefordert. Wenn Sie sich nicht beim
Domänencontroller anmelden und versuchen, auf eine geschützte Ressource zuzugreifen, werden Sie aufgefordert, Berechtigungsnachweise einzugeben.