System login configuration entry settings for JAAS
Specify a list of JAAS system login configurations.
Security > Global security > Authentication > Java Authentication and Authorization Service > System logins
Do not remove the following system login modules:
- RMI_INBOUND
- WEB_INBOUND
- DEFAULT
- RMI_OUTBOUND
- SWAM
- SWAM
- wssecurity.IDAssertion
- wssecurity.signature
- wssecurity.PKCS7
- wssecurity.PkiPath
- wssecurity.UsernameToken
- wssecurity.X509BST
- LTPA
- LTPA_WEB
- DESERIALIZE_ASYNCH_CONTEXT
LTPA_WEB and WEB_INBOUND perform similar functions. IBM recommends that we use WEB_INBOUND since it is the newer of the system login modules.
RMI_INBOUND, WEB_INBOUND, DEFAULT
Process inbound login requests for Remote Method Invocation (RMI), web applications, and most of the other login protocols.
RMI_INBOUND Handle logins for inbound RMI requests. Typically, these logins are requests for authenticated access to EJB files. When using the RMI connector, these logins might be requests for JMX. WEB_INBOUND Handle logins for web application requests, which include servlets and JSP files. This login configuration can interact with the output generated from a trust association interceptor (TAI), if configured. The Subject that is passed into the WEB_INBOUND login configuration might contain objects generated by the TAI. DEFAULT Handle the logins for inbound requests that are made by most of the other protocols and internal authentications. These three login configurations will 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 the application server authenticates the user.
- Callback
callbacks[0] = new javax.security.auth.callback.
NameCallback("Username:");
- Responsibility
- Collect the user name 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 without a password.
- Callback
callbacks[1] = new javax.security.auth.callback.
PasswordCallback("Password:", false);
- Responsibility
- Collect the password provided during a login. A password of null is allowed, and is used to support identity assertion.
- Callback
callbacks[2] = new com.ibm.websphere.security.auth.callback.
WSCredTokenCallbackImpl("Credential Token:");
- Responsibility
- Collect the 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
- Collect the ArrayList list of the TokenHolder objects that are returned from the call to the WSOpaqueTokenHelper. The callback uses the createTokenHolderListFromOpaqueToken method with the Common Secure Interoperability version 2 (CSIv2) authorization token as input. 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. We must enable security attribute propagation for both the outbound and inbound authentication.
We can enable the Security attribute propagation option for CSIv2 outbound authentication by completing the following steps:
Security > Global security > Authentication > RMI/IIOP security > CSIv2 outbound authentication > Security attribute propagation
We can enable the Security attribute propagation option for CSIv2 inbound authentication:
Security > Global security > Authentication > RMI/IIOP security > CSIv2 inbound authentication > Security attribute propagation
In system login configurations, the application server authenticates the user based upon the information that is 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:
- The callbacks[0] = new javax.security.auth.callback.NameCallback("Username:"); callback only
This callback occurs for CSIv2 identity assertion, web and CSIv2 X509 certificate logins, old-style trust association interceptor logins, and so on. In web and CSIv2 X509 certificate logins, the application server maps the certificate to a user name. This callback is used by any login type that establishes trust with the user name only.
- Both the callbacks[0] = new javax.security.auth.callback.NameCallback("Username:"); callback and the callbacks[1] = new javax.security.auth.callback.PasswordCallback("Password:", false); callbacks.
This combination of callbacks is typical for basic authentication logins. Most user authentications occur using these two callbacks.
- The callbacks[2] = new com.ibm.websphere.security.auth.callback.WSCredTokenCallbackImpl("Credential Token:"); only
This callback is used to validate an LTPA token. This validation typically occurs during a single sign-on (SSO) or downstream login. Any time a request originates from the application server, instead of a pure client, the LTPA token flows to the target server. For single sign-on (SSO), the LTPA token is received in the cookie and the token is used for login. If a custom login module needs the user name from an LTPA token, the module can use the following method to retrieve the unique ID from the token:
com.ibm.wsspi.security.token.WSSecurityPropagationHelper.validateLTPAToken(byte[])
After retrieving the unique ID, use the following method to get the user name:
com.ibm.wsspi.security.token.WSSecurityPropagationHelper.getUserFromUniqueID(uniqueID)
Any time a custom login module is plugged in ahead of the application server login modules and it changes the identity using a credential mapping service, it is important that this login module validates the LTPA token, if present. Calling the following method is sufficient to validate the trust in the LTPA token:
com.ibm.wsspi.security.token.WSSecurityPropagationHelper.validateLTPAToken(byte[])
The receiving server must have the same LTPA keys as the sending server for this validation to be successful. A security exposure is possible if we do not validate this LTPA token, when present.
- A combination of any of the previously mentioned callbacks plus the callback...
callbacks[3] = new com.ibm.wsspi.security.auth.callback.WSTokenHolderCallback("Authz Token List:");
This callback indicates that some propagated attributes arrived at the server. The propagated attributes still require one of the following authentication methods:
- 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:");
If the attributes are added to the Subject from a pure client, then the NameCallback and PasswordCallback callbacks authenticate the information and the objects that are serialized in the token holder are added to the authenticated Subject. If both CSIv2 identity assertion and propagation are enabled, the application server uses the NameCallback callback and the token holder, which contains all of the propagated attributes, to deserialize most of the objects. WebSphere application server uses the NameCallback callback because trust is established with the servers that you indicate in the CSIv2 trusted server list. To specify trusted servers:
Security > Global security > Authentication > CSIv2 inbound authentication
A custom login module needs to handle custom serialization. See "Security attribute propagation".
In addition to the callbacks defined 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
- Collect 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
- Collect 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 cookie to the response.
- Callback
callbacks[6] = new com.ibm.websphere.security.auth.callback.WSAppContextCallback("ApplicationContextCallback:");
- Responsibility
- Collect the web application context used during the login. This callback consists of a hashtable, which if present contains the application name and the redirected web address.
- Callback
callbacks[7] = new WSRealmNameCallbackImpl("Realm Name:", <default_realm>);
- Responsibility
- Collect the realm name for the login information. The realm information might not always be provided and should be assumed to be the current realm if it is not provided.
- Callback
callbacks[8] = new WSX509CertificateChainCallback("X509Certificate[]:");
- Responsibility
- If the login source is an X509Certificate from SSL client authentication, this callback contains the certificate that was validated by SSL. The ltpaLoginModule calls the same mapping functions as in previous releases. Once it is passed into the login, it provides a custom login module with the opportunity to map the certificate in a custom way. It then performs a hashtable login (see the related link, Custom login module for inbound mapping, for an example of a hashtable login.).
To use security attribute propagation with the WEB_INBOUND login configuration, we can enable the Web inbound security attribute propagation option on the Single sign-on panel.
Security > Global security > Authentication > Web security > Single sign-on (SSO) > Web inbound security attribute propagation
The following login modules are predefined for the RMI_INBOUND, WEB_INBOUND, and DEFAULT system login configurations. We can add custom login modules before, between, or after any of these login modules, but we cannot remove these predefined login modules:
- com.ibm.ws.security.server.lm.ltpaLoginModule
Performs the primary login when attribute propagation is either enabled or disabled. A primary login uses normal authentication information such as a user ID and password, an LTPA token, or a trust association interceptor (TAI) and a certificate distinguished name (DN). If any of the following scenarios are true, this login module is not used and the com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule module performs the primary login:
- The java.util.Hashtable object with the required user attributes is contained in the Subject.
- The java.util.Hashtable object with the required user attributes is present in the sharedState HashMap of the LoginContext.
- The WSTokenHolderCallback callback is present without a specified password. If a user name and a password are present with a WSTokenHolderCallback callback, which indicates propagated information, the request likely originates from either a pure client or a server from a different realm that mapped the existing identity to a user ID and password.
- com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule
This login module performs the primary login using the normal authentication information if any of the following conditions are true:
- A java.util.Hashtable object with required user attributes is contained in the Subject.
- A java.util.Hashtable object with required user attributes is present in the sharedState HashMap of the LoginContext context.
- The WSTokenHolderCallback callback is present without a PasswordCallback callback.
When the java.util.Hashtable object is present, the login module maps the object attributes into a valid Subject. When the WSTokenHolderCallback callback is present, the login module deserializes the byte token objects and regenerates the serialized Subject contents. The java.util.Hashtable hashtable takes precedence over all of the other forms of login. Be careful to avoid duplicating or overriding what the application server might have propagated previously. By specifying a java.util.Hashtable hashtable to take precedence over other authentication information, the custom login module must have already verified the LTPA token, if present, to establish sufficient trust. The custom login module can use the com.ibm.wsspi.security.token.WSSecurityPropagationHelper.validationLTPAToken(byte[]) method to validate the LTPA token present in the WSCredTokenCallback callback. Failure to validate the LTPA token presents a security risk. See: Configuring inbound identity mapping"
RMI_OUTBOUND
Process RMI requests 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:
Security > Global security > Authentication > RMI/IIOP security > 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. When the application server sends both the authentication and authorization information downstream, the application server removes the need to access the user registry again and look up the security attributes of the user for authorization purposes. Additionally, any custom objects that are added at the sending server are present in the Subject at the downstream server.
The following callback is available in the RMI_OUTBOUND login configuration. Use the com.ibm.wsspi.security.csiv2.CSIv2PerformPolicy object 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 the application server must map the realm. See "Configuring outbound mapping to a different target realm" in the information center.
- Callback
- callbacks[0] = new WSProtocolPolicyCallback("Protocol Policy Callback: ");
- Responsibility
Provide 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 policy 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. We can add custom login modules before, between, or after any of these login modules, but we cannot remove these predefined login modules.
- com.ibm.ws.security.lm.wsMapCSIv2OutboundLoginModule
- Retrieve the following tokens and objects before creating an opaque byte sent to another server using the Common Secure Interoperability v2 (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
Use a custom login module prior to this login module to perform credential mapping. However, IBM recommends 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 are processed after this login module acts on the new Subject contents.
See "Configuring outbound mapping to a different target realm" in the information center.
SWAM
Process 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, the application server cannot send requests from server to server. In this case, we must use LTPA. The SWAM login configuration is deprecated and will be removed in a future release.
wssecurity.IDAssertion
Process login configuration requests for Web Services Security using identity assertion. This login configuration is for Web Services Security Draft 13 JAX-RPC (v5.x) applications. See "Identity assertion authentication method" in the information center.
wssecurity.IDAssertionUsernameToken
Process login configuration requests for Web Services Security using identity assertion. This login configuration is for Web Services Security V1.0 JAX-RPC applications.
The custom property com.ibm.wsspi.wssecurity.auth.module.IDAssertionLoginModule.disableUserRegistryCheck can be configured for the JAAS IDAssertionUsernameToken login module. This property is an option for the Web Services Security identity assertion JAAS login module, wssecurity.IDAssertionUsernameToken. The property indicates that the login module should not perform a user registry check when processing an inbound identity token.
wssecurity.PKCS7
Verifies an X.509 certificate with a certificate revocation list in a Public Key Cryptography Standards #7 (PKCS7) object. This login configuration is for v6.0.x systems.
wssecurity.PkiPath
Verify an X.509 certificate with a public key infrastructure (PKI) path. This login configuration is for v6.0.x systems.
wssecurity.signature
Process login configuration requests for Web Services Security using digital signature validation.
This login configuration is for v5.x systems.
wssecurity.UsernameToken
Verify basic authentication (user name and password). When using the JAX-RPC runtime, the following custom properties can be configured for the JAAS UsernameToken login module:
- com.ibm.wsspi.wssecurity.auth.module.UsernameLoginModule.disableUserRegistryCheck
Can be configured for the JAAS UsernameToken login module.
- com.ibm.wsspi.wssecurity.auth.module.UsernameLoginModule
This property is an option for the Web Services Security UsernameToken JAAS login module. The property indicates that the login module should not perform a user registry check when processing an inbound username token.
wssecurity.X509BST
Verify an X.509 binary security token (BST) by checking the validity of the certificate and the certificate path. This login configuration is for v6.0.x systems.
LTPA_WEB
Process login requests to components in the web container such as servlets and JavaServer pages (JSP) files. The com.ibm.ws.security.web.AuthenLoginModule login module is predefined in the LTPA login configuration. We 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 passed in using a callback handler. For more information, see "Example: Customizing a server-side Java Authentication and Authorization Service authentication and logon configuration" in the information center.
LTPA
Process login requests that are not handled by the LTPA_WEB login configuration. This login configuration is used by WAS v6.1 and previous versions. The com.ibm.ws.security.server.lm.ltpaLoginModule login module is predefined in the LTPA login configuration. We can add custom login modules before or after this module in the LTPA login configuration. See "Example: Customizing a server-side JAAS authentication and logon configuration" in the information center.
DESERIALIZE_ASYNCH_CONTEXT
Process login requests for asynchronous beans. The DESERIALIZE_ASYNCH_CONTEXT configuration is used for asynchronous beans only. The scheduler uses the asynchronous beans alarm manager for "Deferred Start", which allows serialization and deserialization of the J2EE context. This login configuration is used when using asynchronous beans, Scheduler, and EJB Timers. The DESERIALIZE_ASYNCH_CONTEXT login configuration has a limitation. Any operation that requires token validation in the lognModules configured in the DESERIALIZE_ASYNC_CONTEXT login configuration can result in the API repeatedly throwing the TokenExpiredException.
Related:
JAAS Security attribute propagation Default implementations of the Web Services Security service provider programming interfaces Configure programmatic logins for JAAS Configure outbound identity mapping to a different target realm Configure inbound identity mapping Customize a server-side JAAS authentication and login configuration Configuration entry settings for JAAS Example: Custom login module for inbound mapping