[Version 5.1.1 and later]System login configuration entry settings for Java Authentication and Authorization Service

Use this page to specify a list of Java Authentication and Authorization Service (JAAS) system login configurations.

To view this administrative console page, click Security > JAAS Configuration > System logins.

Read Java Authentication and Authorization Service before you begin defining additional login modules for authenticating to the WebSphere Application Server security run time. Do not remove the following system login modules:

RMI_INBOUND, WEB_INBOUND, DEFAULT
Processes inbound login requests for Remote Method Invocation (RMI), Web applications, and most of the other login protocols. These login configurations are used by WebSphere Application Server Version 5.1.1
RMI_INBOUND
The RMI_INBOUND login configuration handles logins for inbound RMI requests. Typically, these logins are requests for authenticated access to Enterprise JavaBeans (EJB) files. Also, these logins might be Java Management Extensions (JMX) requests when using the RMI connector.
WEB_INBOUND
The WEB_INBOUND login configuration handles logins for Web application requests, which includes servlets and JavaServer Pages (JSP) files. This login configuration can interact with the output that is generated from a trust association interceptor (TAI), if configured. The Subject passed into the WEB_INBOUND login configuration might contain objects that are generated by the TAI.
DEFAULT
The DEFAULT login configuration handles the logins for inbound requests made by most of the other protocols and internal authentications.

These three login configurations can pass in the following callback information, which is handled by the login modules within these configurations. These callbacks are not passed in at the same time. However, the combination of these callbacks determines how WebSphere Application Server authenticates the user.

Callback
callbacks[0] = new javax.security.auth.callback.
NameCallback("Username: ");
Responsibility
Collects the user name that is provided during a login. This information can be the user name for the following types of logins:
  • User name and password login, which is known as basic authentication.
  • User name only for identity assertion.
Callback
callbacks[1] = new javax.security.auth.callback.
PasswordCallback("Password: ", false);
Responsibility
Collects the password that is provided during a login.
Callback
callbacks[2] = new com.ibm.websphere.security.auth.callback.
WSCredTokenCallbackImpl("Credential Token: ");
Responsibility
Collects the Lightweight Third Party Authentication (LTPA) token (or other token type) during a login. Typically, this information is present when a user name and a password are not present.
Callback
callbacks[3] = new com.ibm.wsspi.security.auth.callback.
WSTokenHolderCallback("Authz Token List: ");
Responsibility
Collects the ArrayList of the TokenHolder objects that are returned from the call to the WSOpaqueTokenHelper. createTokenHolderListFromOpaqueToken () method using the Common Secure Interoperability version 2 (CSIv2) authorization token as input.

Note: This callback is present only when the Security Attribute Propagation option is enabled and this login is a propagation login. In a propagation login, (sufficient security attributes are propagated with the request to prevent having to access the user registry for additional attributes.

In system login configurations, WebSphere Application Server authenticates the user based upon the information collected by the callbacks. However, a custom login module does not need to act upon any of these callbacks. The following list explains the typical combinations of these callbacks:

In addition to the callbacks that aredefined previously, the WEB_INBOUND login configuration can contain the following additional callbacks only:

Callback
callbacks[4] = new com.ibm.websphere.security.auth.callback.
WSServletRequestCallback("HttpServletRequest: ");
Responsibility
Collects the HTTP servlet request object, if presented. This callback enables login modules to retrieve information from the HTTP request to use during a login.
Callback
callbacks[5] = new com.ibm.websphere.security.auth.callback.
WSServletResponseCallback("HttpServletResponse: ");
Responsibility
Collects the HTTP servlet response object, if presented. This callback enables login modules to add information into the HTTP response as a result of the login. For example, login modules might add the SingleSignonCookie to the response.
Callback
callbacks[6] = new com.ibm.websphere.security.auth.callback.
WSAppContextCallback("ApplicationContextCallback: ");
Responsibility
Collects the Web application context used during the login. This callback consists of a Hashtable, which contains the application name and the redirect Web address, if present.

The following login modules are predefined for the RMI_INBOUND, WEB_INBOUND, and DEFAULT system login configurations. You can add custom login modules before, between, or after any of these login modules, but you cannot remove these predefined login modules.

RMI_OUTBOUND
Processes Remote Method Invocation (RMI) requests that are sent outbound to another server when either the com.ibm.CSI.rmiOutboundLoginEnabled or the com.ibm.CSIOutboundPropagationEnabled properties are true.

These properties are set in the CSIv2 authentication panel. To access the panel, click Security > Authentication protocol > CSIv2 Outbound authentication. To set the com.ibm.CSI.rmiOutboundLoginEnabled property, select Custom outbound mapping. To set the com.ibm.CSIOutboundPropagationEnabled property, select the Security attribute propagation option.

This login configuration determines the security capabilities of the target server and its security domain. For example, if WebSphere Application Server Version 5.1.1 communicates with a version 5.x Application Server, then the Version 5.1.1 application server sends the authentication information only, using an LTPA token, to the version 5.x Application Server. However, if WebSphere Application Server Version 5.1.1 communicates with a Version 5.1.x Application Server, the authentication and authorization information is sent to the receiving application server if propagation is enabled at both the sending and receiving servers. When the application server sends both the authentication and authorization information downstream, it removes the need to re-access the user registry and look up the security attributes of the user for authorization purposes. Additionally, any custom objects added at the sending server should be present in the Subject at the downstream server.

The following callback is available to in the RMI_OUTBOUND login configuration. You can use the com.ibm.wsspi.security.csiv2.CSIv2PerformPolicy object that is returned by this callback to query the security policy for this particular outbound request. This query can help determine if the target realm is different than the current realm and if WebSphere Application Server must map the realm. For more information, see "Configuring outbound mapping to a different target realm".

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

Provides protocol-specific policy information for the login modules on this outbound invocation. This information is used to determine the level of security, including the target realm, target security requirements, and coalesced security requirements.

The following method obtains the CSIv2PerformPolicy from this specific login module:

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

A different protocol other than RMI might have a different type of policy object.

The following login module is predefined in the RMI_OUTBOUND login configuration. You can add custom login modules before, between, or after any of these login modules, but you cannot remove these predefined login modules.

com.ibm.ws.security.lm.wsMapCSIv2OutboundLoginModule
Retrieves the following tokens and objects before creating an opaque byte that is sent to another server using the Common Secure Interoperability Version 2 (CSIv2) authorization token layer:
  • Forwardable com.ibm.wsspi.security.token.Token implementations from the Subject
  • Serializable custom objects from the Subject
  • Propagation tokens from the thread

You can use a custom login module prior to this login module to perform credential mapping. However, it is recommended that the login module change the contents of the Subject that is passed in during the login phase. If this recommendation is followed, the login modules processed after this login module act on the new Subject contents.

For more information, see " Configuring outbound mapping to a different target realm".

SWAM
Processes login requests in a single server environment when Simple WebSphere Authentication Mechanism (SWAM) is used as the authentication method.

SWAM does not support forwardable credentials. When SWAM is the authentication method, WebSphere Application Server cannot send requests from server to server. In this case, you must use LTPA.

wssecurity.IDAssertion
Processes login configuration requests for Web services security using identity assertion.
wssecurity.signature
Processes login configuration requests for Web services security using digital signature validation.
LTPA_WEB
Processes login requests used by the Web container such as servlets and JavaServer pages (JSP) files.

This login configuration is used by WebSphere Application Server Version 5.1. This login configuration was introduced in version 5.1 and is no longer used in version 5.1.1.

The com.ibm.ws.security.web.AuthenLoginModule login module is predefined in the LTPA login configuration. You can add custom login modules before or after this module in the LTPA_WEB login configuration.

The LTPA_WEB login configuration can process the HttpServletRequest object, the HttpServletResponse object, and the Web application name that are passed in using a callback handler. For more information, see "Customizing a server-side Java Authentication and Authorization Service authentication and login configuration" in the documentation.

LTPA
Processes login requests that are not handled by the LTPA_WEB login configuration.

This login configuration is used by WebSphere Application Server Version 5.1 and previous versions.

The com.ibm.ws.security.server.lm.ltpaLoginModule login module is pre-defined in the LTPA login configuration. You can add custom login modules before or after this module in the LTPA login configuration. For more information, see "Customizing a server-side Java Authentication and Authorization Service authentication and login configuration" in the documentation.

Related information

Administrative console buttons
Administrative console page features
Administrative console scope settings
Administrative console filter settings
Administrative console preference settings
Configuration entry settings for Java Authentication and Authorization Service