Ausgangseinstellungen der Systemanmeldekonfiguration für den 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 zum Anzeigen dieser Seite der Administrationskonsole die folgenden Schritte aus:
  1. Klicken Sie auf Sicherheit > Globale Sicherheit.
  2. 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 WAS-Sicherheit definieren. Entfernen Sie nicht die folgenden Systemanmeldemodule:
ICSF [z/OS]

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
Callback

callbacks[1] = new javax.security.auth.callback.PasswordCallback("Password: ", false);

Aufgabe
Erfasst das während der Anmeldung angegebene Kennwort.
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 Benutzer-Registry 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:
  1. Klicken Sie auf Sicherheit > Globale Sicherheit.
  2. Erweitern Sie unter "Authentifizierung" den Eintrag "RMI/IIOP-Sicherheit", und klicken Sie auf Abgehende Authentifizierung gemäß CSIv2.
  3. 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:
  1. Klicken Sie auf Sicherheit > Globale Sicherheit.
  2. Erweitern Sie unter "Authentifizierung" den Eintrag "RMI/IIOP-Sicherheit", und klicken Sie auf Eingehende Authentifizierung gemäß CSIv2.
  3. 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:

  • Einzelner 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.

  • Kombination aus den 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.

  • Einzelner 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 Token-Halter 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 Abschnitt "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-Servlet-Anforderungsobjekt, 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-Servlet-Antwortobjekt, 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 Realm-Namen für die Anmeldeinformationen. Die Realm-Informationen 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 "Agnepasstes 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.
  1. Klicken Sie auf Sicherheit > Globale Sicherheit.
  2. Erweitern Sie unter "Authentifizierung" den Eintrag "Websicherheit", und klicken Sie auf Single Sign-On (SSO).
  3. 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:
  1. Klicken Sie auf Sicherheit > Globale Sicherheit.
  2. Erweitern Sie unter "Authentifizierung" den Eintrag "RMI/IIOP-Sicherheit", und klicken Sie auf Abgehende Authentifizierung gemäß CSIv2.
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. Wenn beispielsweise Application Server Version 5.1.1 oder höher (oder 5.1.0.2 for z/OS) mit Application Server der Version 5.x kommuniziert, sendet nur der Application Server Version 5.1.1 die Authentifizierungsinformationen mit einem LTPA-Token an den Application Server der Version 5.x. Wenn WebSphere Application Server ab Version 5.1.1 jedoch mit einem Application Server der Version 5.1.x kommuniziert, werden die Authentifizierungs- und Berechtigungsinformationen an den empfangenden Anwendungsserver gesendet, sofern die Weitergabe sowohl auf dem sendenden als auch dem empfangenden Server aktiviert ist. Sendet der Anwendungsserver die Authentifizierungs- und Berechtigungsinformationen an einen untergeordneten Server, muss kein erneuter Zugriff auf die Benutzer-Registry 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 Ziel-Realm vom aktuellen Realm abweicht und vom Anwendungsserver zugeordnet werden muss. Weitere Informationen hierzu finden Sie Information Center in dem Artikel, der sich mit der Konfiguration der Zuordnung abgehender Anforderungen zu einem anderen Ziel-Realm befasst.

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 Ziel-Realm, 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.Token-Implementierungen 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 Information Center in dem Artikel, der sich mit der Konfiguration der Zuordnung abgehender Anforderungen zu einem anderen Ziel-Realm befasst.

SWAM [AIX Solaris HP-UX Linux Windows] [iSeries]

Verarbeitet Anmeldeanforderungen in einer Einzelserverumgebung wenn als Authentifizierungsverfahren 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.
[z/OS] Anmerkung: Beachten Sie jedoch, dass SWAM im Application Server Version 7.0 veraltet ist und in einem der künftigen Releases entfernt wird.
SWAM [z/OS]

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

[z/OS] Anmerkung: Beachten Sie jedoch, dass SWAM im Application Server Version 7.0 veraltet ist und in einem der künftigen Releases entfernt wird.
wssecurity.IDAssertion

Verarbeitet Anforderungen der Anmeldekonfiguration nach Web-Service-Sicherheit mit Zusicherung der Identität.

Diese Anmeldekonfiguration ist für Systeme mit Version 5.x bestimmt. Weitere Informationen hierzu finden Sie im Artikel zur Authentifizierungsmethode IDAssertion (Zusicherung der Identität) im Information Center.

wssecurity.PKCS7

Diese Konfiguration überprüft X.509-Zertifikate anhand von Zertifikatwiderruflisten 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-Service-Sicherheit 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).

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

wssecurity.X509BST

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

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

LTPA_WEB

Verarbeitet Anmeldeanforderungen für Komponenten im Webcontainer, 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 5.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.




Mit (online) gekennzeichnete Links setzen einen Internet-Zugang voraus.

Zugehörige Konzepte
Zugehörige Tasks
Zugehörige Verweise
Konfigurationseintragseinstellungen für Java Authentication and Authorization Service


Dateiname: usec_sysjaas.html