Filter für die SPNEGO-Webauthentifizierung über die Administrationskonsole hinzufügen oder modifizieren
Die SPNEGO-Filterwerte (Protected GSS-API Negotiation Mechanism) steuern verschiedene Aspekte von SPNEGO. In der Administrationskonsole können Sie für jeden Anwendungsserver andere Filterwerte angeben.
Vorgehensweise
- Klicken Sie in der Administrationskonsole auf Sicherheit > Globale Sicherheit.
- Klicken Sie unter "Authentifizierung" auf "Web- und SIP-Sicherheit", und klicken Sie auf SPNEGO-Webauthentifizierung.
- Wählen Sie unter "SPNEGO-Filter:" den Namen eines vorhandenen Hosts aus, der editiert werden soll, oder klicken Sie auf Neu.
- Wenn Sie einen neuen Filter erstellen, geben Sie einen Hostnamen von WebSphere Application Server ein. Die ist der Hostnamensabschnitt des Kerberos-Service-Principal-Namens (SPN), den SPNEGO verwendet, um einen gesicherten Kerberos-Kontext herzustellen.
- Geben Sie einen Kerberos-Realmnamen ein. In den meisten Fällen ist der Realm der Domänenname in Großbuchstaben. Beispielsweise verwendet eine Maschine mit dem Domänennamen test.austin.ibm.com in der Regel den Kerberos-Realmnamen AUSTIN.IBM.COM.
- Geben Sie im Feld Filterbedingungen Ihre Filterbedingung ein. Die Filterbedingungen sind der Filterparameter, den die von SPNEGO verwendete
Java™-Klasse verwendet. Sie definiert beliebige Bedingungen, die für die verwendete Implementierungsklasse
aussagefähig sind.
Weitere Informationen zu den Filterkriterien finden Sie im Artikel SPNEGO-Webauthentifizierung über die Administrationskonsole aktivieren und konfigurieren.
- Geben Sie im Feld Filterklasse den Namen der Java-Klasse ein, den SPNEGO zur Auswahl der HTTP-Anforderungen, die der SPNEGO-Authentifizierung unterliegen, verwendet. Wenn Sie diesen Parameter nicht angeben, wird die Standardfilterklasse com.ibm.ws.security.spnego.HTTPHeaderFilter verwendet.
- Optional: Im Feld URL der Fehlerseite für "SPNEGO nicht unterstützt" können Sie wahlweise den URL einer Ressource eingeben, die den Inhalt enthält, den SPNEGO in die HTTP-Antwort einfügt, die von der (Browser-) Clientanwendung angezeigt wird, wenn die SPNEGO-Authentifizierung nicht unterstützt wird. Diese Eigenschaft kann eine Webressource (http://) oder eine Dateiressource (file://) angeben.
- Optional: Im Feld
URL der Fehlerseite "NTLM-Token empfangen" können Sie wahlweise den URL einer Ressource eingeben, die den Inhalt enthält, den
SPNEGO in die HTTP-Antwort einfügt, die von der Browserclientanwendung angezeigt wird. Die Browserclientanwendung
zeigt diese HTTP-Antwort an, wenn der Browserclient während des Handshake mit Anforderung/Antwortaustausch ein NTLM-Token (NT LAN Manager)
an Stelle des erwarteten SPNEGO-Token sendet.
Diese Eigenschaft kann eine Webressource (http://) oder eine Dateiressource (file://) angeben.
- Optional: Wählen Sie Kerberos-Realm vom Namen des Principals abtrennen aus, um festzulegen, ob SPNEGO das Suffix des Principal-Benutzernamens ab dem Zeichen "@" vor dem Kerberos-Realmnamen entfernen soll. Ist diese Option ausgewählt, wird das Suffix des Principal-Benutzernamens entfernt. Das Suffix des Principal-Namens bleibt erhalten, wenn diese Option nicht ausgewählt ist. Diese Option ist standardmäßig ausgewählt.
- Optional: Wählen Sie Übertragung der Kerberos-Berechtigungsnachweise aktivieren aus, um festzulegen, ob die von
übertragenen Kerberos-Berechtigungsnachweise von SPNEGO gespeichert werden sollen. Diese Option bietet einer Anwendung außerdem die Möglichkeit, die gespeicherten Berechtigungsnachweise abzurufen
und an andere nachgeordnete Anwendungen für eine zusätzliche
SPNEGO-Authentifizierung weiterzugeben.Anmerkung: Wenn diese Option aktiviert ist (Standardeinstellung), ist der GSSCredential-Berechtigungsnachweis nicht serialisierbar und kann nicht an den nachgeschalteten (Downstream-)Server weitergegeben werden. Der Berechtigungsnachweis für die Kerberos-Clientdelegierung wird extrahiert, und die KRBAuthnToken-Basis wird erstellt. Das KRBAuthnToken enthält die Kerberos-Clientdelegierung und kann an einen nachgeschalteten (Downstream-)Server weitergegeben.
Wenn Sie das KRBAuthnToken an einen nachgeschalteten (Downstream-)Server weitergeben möchten, muss das Client-TGT (Ticket Granting Ticket) Optionen zur Weiterleitung enthalten, für die keine Adresse festgelegt ist. Wenn ein Client-TGT adressiert ist, hat der nachgeschaltete (Downstream-) nach der Weitergabe keinen Berechtigungsnachweis für die GSS-Clientdelegierung.
Sie können den GSSCredential-Berechtigungsnachweis für Clientdelegierung mit der Methode "KRBAuthnToken.getGSSCredential()" aus dem KRBAuthnToken extrahieren.
- Klicken Sie auf OK.
Ergebnisse


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_SPNEGO_add_filter
Dateiname:tsec_SPNEGO_add_filter.html