Einstellungen für Einträge der Systemanmeldekonfiguration für Java Authentication and Authorization Service

Verwenden Sie diese Seite, wenn Sie eine Liste von Systemanmeldekonfigurationen für den JAAS (Java Authentication and Authorization Service) angeben möchten.

Führen Sie die folgenden Schritte aus, um diese Seite der Administrationskonsole anzuzeigen:

Klicken Sie auf Sicherheit > Globale Sicherheit.
Klicken Sie unter "Authentifizierung" auf Java Authentication and Authorization Service > Systemanmeldungen.

Lesen Sie die Dokumentation zum Java Authentication and Authorization Service, bevor Sie zusätzliche Module für die Authentifizierung durch die Laufzeit der Application-Server-Sicherheit definieren. Entfernen Sie nicht die folgenden Systemanmeldemodule:

RMI_INBOUND
WEB_INBOUND
DEFAULT
RMI_OUTBOUND
SWAM
SWAM
wssecurity.IDAssertion
wssecurity.signature
wssecurity.PKCS7
wssecurity.PkiPath
wssecurity.UsernameToken
wssecurity.X509BST
LTPA
LTPA_WEB
Anmerkung: LTPA_WEB und WEB_INBOUND führen ähnliche Funktionen aus. Es wird empfohlen, WEB_INBOUND zu verwenden, da WEB_INBOUND das neuere der Systemanmeldemodule ist.
DESERIALIZE_ASYNCH_CONTEXT

ICSF

Verarbeitet Anmeldeanforderungen, wenn Integrated Cryptographic Services Facility (ICSF) als Authentifizierungsverfahren verwendet wird.

RMI_INBOUND, WEB_INBOUND, DEFAULT

Verarbeitet ankommende Anmeldeanforderungen für RMI-Webanwendungen (Remote Method Invocation) und die meisten anderen Anmeldeprotokolle.

RMI_INBOUND: Diese Anmeldekonfiguration verarbeitet Anmeldungen für ankommende RMI-Anforderungen. Diese Anmeldungen sind in der Regel Anforderungen nach einem authentifizierten Zugriff auf EJB-Dateien. Bei Verwendung des RMI-Connectors können diese Anmeldungen auch JMX-Anforderungen (Java Management Extensions) sein.
WEB_INBOUND: Diese Anmeldekonfiguration verarbeitet die Anmeldungen für Webanwendungsanforderungen, einschließlich Servlets und JavaServer Pages (JSP). Diese Anmeldekonfiguration kann mit der Ausgabe interagieren, die von einem TAI (Trust Association Interceptor) generiert wird, sofern ein solcher konfiguriert ist. Das an die Anmeldekonfiguration WEB_INBOUND übergebene Subjekt kann vom TAI generierte Objekte enthalten.
DEFAULT: Die Anmeldekonfiguration verarbeitet die Anmeldungen für ankommende Anforderungen von der Mehrzahl der übrigen Protokolle und internen Authentifizierungen.

Diese drei Anmeldekonfigurationen übergeben die folgenden Callback-Informationen, die von den Anmeldemodulen in diesen Konfigurationen bearbeitet werden. Diese Callbacks werden nicht zur gleichen Zeit übergeben. Die Kombination der Callbacks bestimmt jedoch, wie der Anwendungsserver den Benutzer authentifiziert.

Callback

callbacks[0] = new javax.security.auth.callback.
NameCallback("Username:");

Aufgabe

Erfasst den während der Anmeldung angegebenen Benutzernamen. Dies kann der Benutzername für folgende Arten von Anmeldungen sein:

Anmeldung mit Benutzername und Kennwort (auch als Basisauthentifizierung bezeichnet)
Nur Angabe des Benutzernamens für Zusicherung der Identität ohne Kennwort.

Callback: callbacks[1] = new javax.security.auth.callback.
PasswordCallback("Password:", false);
Aufgabe: Erfasst das während der Anmeldung angegebene Kennwort. Ein Kennwort mit Nullwert ist zulässig und wird zur Unterstützung der Identitätszusicherung verwendet.

Callback: callbacks[2] = new com.ibm.websphere.security.auth.callback.
WSCredTokenCallbackImpl("Credential Token:");
Aufgabe: Erfasst während der Anmeldung das LTPA-Token (Lightweight Third Party Authentication) oder das Token eines anderen Typs. Diese Information liegt in der Regel vor, wenn kein Benutzername und kein Kennwort vorhanden ist.

Callback

callbacks[3] = new com.ibm.wsspi.security.auth.callback.
WSTokenHolderCallback("Authz Token List:");

Aufgabe

Erfasst die Liste ArrayList der TokenHolder-Objekte, die der Aufruf von WSOpaqueTokenHelper zurückgibt. Der Callback verwendet die Methode createTokenHolderListFromOpaqueToken mit dem CSIv2-Berechtigungstoken (Common Secure Interoperability Version 2) als Eingabe.

Einschränkung: Dieser Callback ist nur vorhanden, wenn die Option Weitergabe von Sicherheitsattributen aktiviert und dies eine Anmeldung mit Weitergabe ist. Bei einer Anmeldung mit Weitergabe werden genug Sicherheitsattribute mit der Anforderung weitergegeben, um einen Zugriff auf die Benutzerregistry wegen zusätzlicher Attribute zu verhindern. Sie müssen die Weitergabe von Sicherheitsattributen sowohl für die abgehende als auch für die eingehende Authentifizierung aktivieren.

Gehen Sie wie folgt vor, um die Option Weitergabe von Sicherheitsattributen für die abgehende Authentifizierung gemäß CSIv2 zu aktivieren:

Klicken Sie auf Sicherheit > Globale Sicherheit.
Erweitern Sie unter "Authentifizierung" den Eintrag "RMI/IIOP-Sicherheit", und klicken Sie auf Authentifizierung abgehender CSIv2-Anforderungen.
Aktivieren Sie die Option Weitergabe von Sicherheitsattributen.

Gehen Sie wie folgt vor, um die Option Weitergabe von Sicherheitsattributen für die eingehende Authentifizierung gemäß CSIv2 zu aktivieren:

Klicken Sie auf Sicherheit > Globale Sicherheit.
Erweitern Sie unter "Authentifizierung" den Eintrag "RMI/IIOP-Sicherheit", und klicken Sie auf Eingehende Authentifizierung gemäß CSIv2.
Aktivieren Sie die Option Weitergabe von Sicherheitsattributen.

In Systemanmeldekonfigurationen authentifiziert der Anwendungsserver den Benutzer basierend auf den Informationen, die von den Callbacks erfasst wurden. Ein angepasstes Anmeldemodul muss jedoch nicht auf diese Callbacks einwirken. Nachfolgend sind die typischen Kombinationen dieser Callbacks aufgelistet und erläutert:

Nur Callback "callbacks[0] = new javax.security.auth.callback.NameCallback("Username:");"
Diesen Callback gibt es bei der CSIV2-Zusicherung der Identität, der Web- und CSIV2-Anmeldung mit X509-Zertifikaten, der althergebrachten Anmeldung mit TAI usw. Bei Web- und CSIV2-Anmeldungen mit X509-Zertifikat ordnet der Anwendungsserver das Zertifikat einem Benutzernamen zu. Dieser Callback wird von allen Anmeldetypen verwendet, bei denen die Anerkennung nur anhand des Benutzernamens erfolgt.
Callbacks "callbacks[0] = new javax.security.auth.callback.NameCallback("Username:");" und "callbacks[1] = new javax.security.auth.callback.PasswordCallback("Password:", false);"
Diese Callback-Kombination ist typisch für Anmeldungen mit Basisauthentifizierung. Für die meisten Benutzerauthentifizierungen werden diese beiden Callbacks verwendet.
Nur Callback "callbacks[2] = new com.ibm.websphere.security.auth.callback.WSCredTokenCallbackImpl("Credential Token:");"
Mit diesem Callback wird ein LTPA-Token (Lightweight Third Party Authentication) ausgewertet. Diese Auswertung wird in der Regel bei SSO (Single Sign-On) oder nachgeschalteten Anmeldungen durchgeführt. Immer, wenn eine Anforderung vom Anwendungsserver und nicht von einem reinen Client stammt, wird das LTPA-Token an den Zielserver gesendet. Beim SSO (Single Sign-On) wird das LTPA-Token im Cookie empfangen und für die Anmeldung verwendet. Wenn ein angepasstes Anmeldemodul den Benutzernamen aus einem LTPA-Token benötigt, kann das Modul die eindeutige ID mit der folgenden Methode aus dem Token abrufen:
com.ibm.wsspi.security.token.WSSecurityPropagationHelper.
validateLTPAToken(byte[])
Verwenden Sie nach dem Abrufen der eindeutigen ID die folgende Methode, um den Benutzernamen anzufordern:
com.ibm.wsspi.security.token.WSSecurityPropagationHelper.
getUserFromUniqueID(uniqueID)

Wichtig: Immer, wenn das Plug-in eines angepassten Anmeldemoduls den Anmeldemodulen des Anwendungsservers vorgeschaltet wird und die Identität mit dem Service für die Zuordnung von Berechtigungsnachweisen ändert, ist es wichtig, dass dieses Modul das LTPA-Token, sofern vorhanden, validiert. Zur Auswertung der Vertrauensstellung im LTPA-Token reicht es aus, die folgende Methode aufzurufen:
com.ibm.wsspi.security.token.WSSecurityPropagationHelper.
validateLTPAToken(byte[])
Dieser Aufruf kann nur funktionieren, wenn der empfangende Server dieselben LTPA-Schlüssel wie der sendende Server hat. Wenn dieses LTPA-Token vorhanden ist und nicht ausgewertet wird, besteht ein Sicherheitsrisiko.
Eine Kombination aus einem der oben aufgeführten Callbacks und dem Callback "callbacks[3] = new com.ibm.wsspi.security.auth.callback.WSTokenHolderCallback("Authz Token List:");"
Dieser Callback gibt an, das einige weitergegebene Attribute beim Server angekommen sind. Die weitergegebenen Attribute erfordern eine der folgenden Authentifizierungsmethoden:
- callbacks[0] = new javax.security.auth.callback.
  NameCallback("Username:");
- callbacks[1] = new javax.security.auth.callback.
  PasswordCallback("Password:", false);
- callbacks[2] = new com.ibm.websphere.security.auth.callback.
  WSCredTokenCallbackImpl("Credential Token:");
Werden die Attribute von einem reinen Client zum Subjekt hinzugefügt, authentifizieren die Callbacks NameCallback und PasswordCallback die Informationen. Die im Tokenhalter serialisierten Objekte werden dann zum authentifizierten Subjekt hinzugefügt.
Wenn sowohl die CSIV2-Zusicherung der Identität als auch die Weitergabe aktiviert sind, verwendet der Anwendungsserver den NameCallback und den Tokenhalter mit allen weitergegebenen Attributen, um die meisten Objekte zu entserialisieren. Der Anwendungsserver verwendet den NameCallback, weil die Server, die in der Liste der anerkannten CSIV2-Server enthalten sind, akzeptiert werden. Gehen Sie wie folgt vor, um anerkannte Server anzugeben:
1. Klicken Sie auf Sicherheit > Globale Sicherheit.
2. Klicken Sie unter "Authentifizierung" auf Eingehende Authentifizierung gemäß CSIv2.
Ein angepasstes Anmeldemodul muss die angepasste Serialisierung verarbeiten. Weitere Informationen hierzu finden Sie im Artikel "Weitergabe von Sicherheitsattributen" im Information Center.

Neben den bereits definierten Callbacks kann die Anmeldekonfiguration WEB_INBOUND nur noch die folgenden Callbacks enthalten:

Callback: callbacks[4] = new com.ibm.websphere.security.auth.callback.
WSServletRequestCallback("HttpServletRequest:");
Aufgabe: Erfasst das HTTP-Servletanforderungsobjekt, sofern ein solches vorliegt. Dieser Callback ermöglicht Anmeldemodulen, Informationen aus der HTTP-Anforderung abzurufen, um diese dann bei der Anmeldung zu verwenden.

Callback: callbacks[5] = new com.ibm.websphere.security.auth.callback.
WSServletResponseCallback("HttpServletResponse:");
Aufgabe: Erfasst das HTTP-Servletantwortobjekt, sofern ein solches vorliegt. Dieser Callback ermöglicht Anmeldemodulen, im Ergebnis der Anmeldung Informationen zur HTTP-Antwort hinzuzufügen. Anmeldemodule könnten beispielsweise das SingleSignonCookie zur Antwort hinzufügen.

Callback: callbacks[6] = new com.ibm.websphere.security.auth.callback.
WSAppContextCallback("ApplicationContextCallback:");
Aufgabe: Erfasst den während der Anmeldung verwendeten Webanwendungskontext. Dieser Callback besteht aus einer Hash-Tabelle, die den Anwendungsnamen und, sofern vorhanden, die umgeleitete Webadresse enthält.
Callback: callbacks[7] = new WSRealmNameCallbackImpl("Realm Name:", <default_realm>);
Aufgabe: Erfasst den Realmnamen für die Anmeldeinformationen. Die Realminformationen sind möglicherweise nicht immer angegeben. Wenn sie nicht angegeben sind, sollte vom aktuellen Realm ausgegangen werden.
Callback: callbacks[8] = new WSX509CertificateChainCallback("X509Certificate[]:");
Aufgabe: Wenn die Anmeldequelle ein X509-Zertifikat aus einer SSL-Clientauthentifizierung ist, enthält dieser Callback das Zertifikat, das von SSL validiert wurde. Das Modul ltpaLoginModule ruft dieselben Zuordnungsfunktionen wie in den früheren Releases auf. Nachdem es an die Anmeldung übergeben wurde, kann ein angepasstes Anmeldemodul das Zertifikat auf eine eigene Weise zuordnen. Anschließend wird eine Anmeldung mit Hash-Tabelle vorgenommen. Unter dem zugehörigen Link "Angepasstes Anmeldemodul für eingehende Zuordnung" finden Sie ein Beispiel für eine Anmeldung mit Hash-Tabelle. .

Wenn Sie die Weitergabe von Sicherheitsattributen mit der Anmeldekonfiguration WEB_INBOUND nutzen möchten, können Sie die Option Weitergabe der Sicherheitseinstellungen für eingehende Webanforderungen in der Anzeige "Single Sign-On (SSO)" aktivieren.

Klicken Sie auf Sicherheit > Globale Sicherheit.
Erweitern Sie unter "Authentifizierung" den Eintrag "Websicherheit", und klicken Sie auf Single Sign-On (SSO).
Wählen Sie die Option Weitergabe von Sicherheitsattributen für eingehende Webanforderungen aus.

Für die Systemanmeldekonfigurationen RMI_INBOUND, WEB_INBOUND, und DEFAULT sind die folgenden Anmeldemodule vordefiniert. Sie können vor, zwischen oder nach diesen Anmeldemodulen eigene Anmeldemodule hinzufügen, jedoch keines der vordefinierten Anmeldemodule entfernen:

com.ibm.ws.security.server.lm.ltpaLoginModule
Dieses Anmeldemodul führt die primäre Anmeldung durch, wenn die Attributweitergabe aktiviert oder inaktiviert ist. Bei einer primären Anmeldung werden die normalen Authentifizierungsinformationen wie Benutzer-ID und Kennwort, ein LTPA-Token oder ein TAI (Trust Association Interceptor) und ein Zertifikat-DN verwendet. Wenn eine der folgenden Situationen vorliegt, wird dieses Anmeldemodul nicht verwendet und die primäre Anmeldung vom Modul com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule ausgeführt:
- Das Objekt java.util.Hashtable mit den erforderlichen Benutzerattributen ist im Subjekt enthalten.
- Das Objekt java.util.Hashtable mit den erforderlichen Benutzerattributen ist in der sharedState HashMap des LoginContext enthalten.
- Der Callback WSTokenHolderCallback liegt ohne angegebenes Kennwort vor. Wenn zusammen mit einem WSTokenHolderCallback, der die weitergegebenen Informationen angibt, ein Benutzername und ein Kennwort vorliegen, stammt die Anforderung wahrscheinlich von einem reinen Client oder einem Server aus einem anderen Realm, der die vorhandene ID einer Benutzer-ID und einem Kennwort zugeordnet hat.
com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule
Dieses Anmeldemodul führt die primäre Anmeldung mit den normalen Authentifizierungsinformationen durch, wenn eine der folgenden Bedingungen erfüllt ist:
- Im Subjekt ist ein Objekt java.util.Hashtable mit erforderlichen Benutzerattributen enthalten.
- In der sharedState HashMap des LoginContext liegt ein Objekt java.util.Hashtable mit erforderlichen Benutzerattributen vor.
- Der Callback WSTokenHolderCallback liegt ohne einen Callback PasswordCallback vor.
Wenn das Objekt java.util.Hashtable vorhanden ist, ordnet das Anmeldemodul die Objektattribute einem gültigen Subjekt zu. Wenn der WSTokenHolderCallback vorliegt, entserialisiert das Anmeldemodul die Bytetokenobjekte und generiert erneut den serialisierten Subjektinhalt. Die java.util.Hashtable hat Vorrang vor allen anderen Formen der Anmeldung. Achten Sie darauf, dass Sie die zuvor vom Anwendungsserver weitergegebenen Attribute nicht duplizieren oder überschreiben.

Wenn Sie eine java.util.Hashtable angeben, die Vorrang vor anderen Authentifizierungsinformationen haben soll, muss das angepasste Anmeldemodul das LTPA-Token (sofern vorhanden) bereits ausgewertet haben, um eine ausreichende Vertrauensstellung zu gewährleisten. Das angepasste Anmeldemodul kann das im WSCredTokenCallback vorhandene LTPA-Token mit der Methode "com.ibm.wsspi.security.token.WSSecurityPropagationHelper.validationLTPAToken(byte[])" auswerten. Wird das LTPA-Token nicht ausgewertet, entsteht ein Sicherheitsrisiko.

Nähere Informationen zum Hinzufügen einer Hash-Tabelle mit anerkannten und korrekt formatierten Attributen, die der Anwendungsserver als Anmeldedaten verwendet, finden Sie im Artikel "Identitätsabgleich für eingehende Anforderungen konfigurieren" im Information Center.

RMI_OUTBOUND

Verarbeitet RMI-Anforderungen, die an einen anderen Server gesendet werden, wenn die Eigenschaft "com.ibm.CSI.rmiOutboundLoginEnabled" oder "com.ibm.CSIOutboundPropagationEnabled" auf "true" gesetzt ist.

Diese Eigenschaften werden in der Anzeige für CSIV2-Authentifizierung festgelegt. Sie können diese Anzeige wie folgt aufrufen:

Klicken Sie auf Sicherheit > Globale Sicherheit.
Erweitern Sie unter "Authentifizierung" den Eintrag "RMI/IIOP-Sicherheit", und klicken Sie auf Authentifizierung abgehender CSIv2-Anforderungen.

Wählen Sie Angepasste Zuordnung abgehender Anforderungen aus, um die Eigenschaft "com.ibm.CSI.rmiOutboundLoginEnabled" zu setzen. Wählen Sie die Option Weitergabe von Sicherheitsattributen aus, um die Eigenschaft "com.ibm.CSIOutboundPropagationEnabled" zu setzen.

Diese Anmeldekonfiguration bestimmt die Sicherheitsfunktionen des Zielservers und seiner Sicherheitsdomäne. Sendet der Anwendungsserver die Authentifizierungs- und Berechtigungsinformationen an einen untergeordneten Server, muss kein erneuter Zugriff auf die Benutzerregistry erfolgen, um für die Autorisierung die Sicherheitsattribute des Benutzers zu suchen. Außerdem sollten im Subjekt auf dem untergeordneten Server alle angepassten, vom sendenden Server hinzugefügten Objekte vorliegen.

Für die Anmeldekonfiguration RMI_OUTBOUND ist der folgende Callback verfügbar. Sie können das von diesem Callback zurückgegebene Objekt com.ibm.wsspi.security.csiv2.CSIv2PerformPolicy verwenden, um die Sicherheitsrichtlinie für diese spezielle abgehende Anforderung abzufragen. Anhand dieser Abfrage kann festgestellt werden, ob der Zielrealm vom aktuellen Realm abweicht und vom Anwendungsserver zugeordnet werden muss. Weitere Informationen hierzu finden Sie im Artikel zur "Konfiguration der Zuordnung abgehender Anforderungen zu einem anderen Zielrealm" im Information Center.

Callback

callbacks[0] = new WSProtocolPolicyCallback("Protocol Policy Callback: ");

Aufgabe

Stellt protokollspezifische Richtlinieninformationen für die Anmeldemodule für diesen abgehenden Aufruf bereit. Mit Hilfe dieser Informationen wird die Sicherheitsstufe einschließlich des Zielrealm, der Sicherheitsvoraussetzungen des Ziels und gemeinsamer Sicherheitsvoraussetzungen bestimmt.

Die folgende Methode empfängt von diesem spezifischen Anmeldemodul die Richtlinie "CSIv2PerformPolicy":

csiv2PerformPolicy = (CSIv2PerformPolicy)
((WSProtocolPolicyCallback)callbacks[0]).getProtocolPolicy();

Ein anderes Protokoll (mit Ausnahme von RMI) kann ein Richtlinienobjekt eines anderen Typs haben.

In der Anmeldekonfiguration RMI_OUTBOUND ist das folgende Anmeldemodul vordefiniert. Sie können vor, zwischen oder nach diesen Anmeldemodulen eigene Anmeldemodule hinzufügen, jedoch keines der vordefinierten Anmeldemodule entfernen.

com.ibm.ws.security.lm.wsMapCSIv2OutboundLoginModule

Ruft die folgenden Token und Objekte ab, bevor ein nicht transparentes Byte erstellt wird, das mit CSIV2 ATL (Authorization Token Layer) an einen anderen Server gesendet wird:

com.ibm.wsspi.security.token.Tokenimplementierungen des Subjekts, die weitergeleitet werden können
Serialisierbare angepasste Objekte des Subjekts
Weitergabetoken vom Thread

Vor diesem Anmeldemodul können Sie ein angepasstes Anmeldemodul für die Zuordnung der Berechtigungsnachweise verwenden. Das Anmeldemodul sollte jedoch den Inhalt des während der Anmeldephase übergebenen Subjekts ändern. Ist dies der Fall, wirken sich die nach diesem Anmeldemodul verarbeiteten Anmeldemodule auf den neuen Subjektinhalt aus.

Weitere Informationen hierzu finden Sie im Artikel zur "Konfiguration der Zuordnung abgehender Anforderungen zu einem anderen Zielrealm" im Information Center.

SWAM

Verarbeitet Anmeldeanforderungen in einer Einzelserverumgebung, wenn als Authentifizierungsmethode SWAM (Simple WebSphere Authentication Mechanism) verwendet wird.

SWAM unterstützt keine weiterleitbaren Berechtigungsnachweise. Wenn das Authentifizierungsverfahren SWAM ist, kann der Anwendungsserver keine Anforderungen von Server zu Server senden. In diesem Fall müssen Sie LTPA verwenden.

Anmerkung: Die Anmeldekonfiguration SWAM ist veraltet und wird in einem der künftigen Releases entfernt.

Anmerkung: Beachten Sie jedoch, dass SWAM im Application Server Version 8.5 veraltet ist und in einem der künftigen Releases entfernt wird.

SWAM

Mit dieser Anmeldekonfiguration können Sie eine ID in einer LDAP-Benutzerregistry einer SAF-Benutzer-ID (System Authorization Facility) zuordnen.

Anmerkung: Beachten Sie jedoch, dass SWAM im Application Server Version 8.5 veraltet ist und in einem der künftigen Releases entfernt wird.

wssecurity.IDAssertion

Verarbeitet Anforderungen der Anmeldekonfiguration nach Web Services Security mit Zusicherung der Identität.

Diese Anmeldekonfiguration ist für JAX-RPC-Anwendungen der Version 5.x bestimmt, die auf der Spezifikation Web Services Security Draft 13 basieren. Weitere Informationen hierzu finden Sie im Artikel zur "Authentifizierung durch Zusicherung der Identität" im Information Center.

wssecurity.IDAssertionUsernameToken

Verarbeitet Anforderungen der Anmeldekonfiguration nach Web Services Security mit Zusicherung der Identität.

Diese Anmeldekonfiguration ist für JAX-RPC-Anwendungen bestimmt, die auf der Spezifikation Web Services Security Version 1.0 basieren.

Die angepasste Eigenschaft "com.ibm.wsspi.wssecurity.auth.module.IDAssertionLoginModule.disableUserRegistryCheck" kann für das JAAS-Anmeldemodul "IDAssertionUsernameToken" konfiguriert werden. Diese Eigenschaft ist eine Option für das JAAS-Anmeldemodul "wssecurity.IDAssertionUsernameToken" für die Identitätszusicherung gemäß Web Services Security. Die Eigenschaft gibt an, dass das Anmeldemodul bei der Verarbeitung eines eingehenden Identitätstokens keine Überprüfung in der Benutzerregistry durchführen soll.

wssecurity.PKCS7

Diese Konfiguration überprüft X.509-Zertifikate anhand von Zertifikatswiderruflisten in einem PKCS7-Objekt (Public Key Cryptography Standards #7).

Diese Anmeldekonfiguration ist für Systeme mit Version 6.0.x bestimmt.

wssecurity.PkiPath

Diese Konfiguration überprüft ein X.509-Zertifikat mit einem PKI-Pfad (Public Key Infrastructure).

Diese Anmeldekonfiguration ist für Systeme mit Version 6.0.x bestimmt.

wssecurity.signature

Verarbeitet Anforderungen der Anmeldekonfiguration nach Web Services Security mit Validierung digitaler Signaturen.

Diese Anmeldekonfiguration ist für Systeme mit Version 5.x bestimmt.

wssecurity.UsernameToken

Diese Konfiguration überprüft die Basisauthentifizierung (Benutzername und Kennwort).

Wenn Sie die JAX-RPC-Laufzeitumgebung verwenden, können die folgenden angepassten Eigenschaften für das JAAS-Anmeldemodul "UsernameToken" konfiguriert werden:

Die angepasste Eigenschaft "com.ibm.wsspi.wssecurity.auth.module.UsernameLoginModule.disableUserRegistryCheck" kann für das JAAS-Anmeldemodul "UsernameToken" konfiguriert werden. Diese Eigenschaft ist eine Option für das JAAS-Anmeldemodul "com.ibm.wsspi.wssecurity.auth.module.UsernameLoginModule" für WSS-UsernameToken. Die Eigenschaft gibt an, dass das Anmeldemodul bei der Verarbeitung eines eingehenden Benutzernamentokens keine Überprüfung in der Benutzerregistry durchführen soll.

wssecurity.X509BST

Diese Konfiguration überprüft X.509 Binary Security Token (BST, binäres Sicherheitstoken), indem sie die Gültigkeit des Zertifikats und des Zertifikatspfads prüft.

Diese Anmeldekonfiguration ist für Systeme mit Version 6.0.x bestimmt.

LTPA_WEB

Verarbeitet Anmeldeanforderungen für Komponenten im Web-Container, wie z. B. Servlets und JSP-Dateien (JavaServer Pages).

In der LTPA-Anmeldekonfiguration ist das Anmeldemodul com.ibm.ws.security.web.AuthenLoginModule vordefiniert. Vor und nach diesem Modul in der Anmeldekonfiguration LTPA_WEB können Sie angepasste Anmeldemodule hinzufügen.

Die Anmeldekonfiguration LTPA_WEB kann das Objekt HttpServletRequestm das Objekt HttpServletResponse und den Namen der Webanwendung verarbeiten. Diese werden von einem Callback-Handler übergeben. Nähere Informationen finden Sie im Artikel "Beispiel: Serverseitige JAAS-Authentifizierungs- und -Anmeldekonfiguration anpassen" im Information Center.

LTPA

Verarbeitet Anmeldeanforderungen, die nicht von der Anmeldeanforderung LTPA_WEB bearbeitet werden.

Diese Anmeldekonfiguration wird bis WebSphere Application Server Version 6.1 verwendet.

In der LTPA-Anmeldekonfiguration ist das Anmeldemodul com.ibm.ws.security.server.lm.ltpaLoginModule vordefiniert. Vor und nach diesem Modul in der LTPA-Anmeldekonfiguration können Sie angepasste Anmeldemodule hinzufügen. Nähere Informationen finden Sie im Artikel "Beispiel: Serverseitige JAAS-Authentifizierungs- und -Anmeldekonfiguration anpassen" im Information Center.

LTPA_WEB

Verarbeitet Anmeldeanforderungen für Komponenten im Web-Container, wie z. B. Servlets und JSP-Dateien (JavaServer Pages).

DESERIALIZE_ASYNCH_CONTEXT

Diese Konfiguration verarbeitet Anforderungen, die sich auf asynchrone Beans beziehen.

Die Konfiguration DESERIALIZE_ASYNCH_CONTEXT wird nur für asynchrone Beans verwendet. Der Scheduler verwendet den Alarmmanager für asynchrone Beans für den verzögerten Start, wodurch die Serialisierung und Entserialisierung des J2EE-Kontextes ermöglicht wird. Diese Anmeldekonfiguration wird für asynchrone Beans, Scheduler und EJB-Zeitgeber verwendet.

Vorsicht:

Die Anmeldekonfiguration DESERIALIZE_ASYNCH_CONTEXT unterliegt einer Einschränkung. Jede Operation, die die Tokenvalidierung in den in der Anmeldekonfiguration DESERIALIZE_ASYNC_CONTEXT konfigurierten loginModules voraussetzt, kann dazu führen, dass die API mehrmals die TokenExpiredException auslöst.

Dateiname: usec_sysjaas.html