System login configuration entry settings for Java Authentication and Authorization Service

Processes login requests when Integrated Cryptographic Services Facility (ICSF) is used as the authentication mechanism.

Processes inbound login requests for Remote Method Invocation (RMI), web applications, and most of the other login protocols.

RMI_INBOUND

This login configuration handles logins for inbound RMI requests. Typically, these logins are requests for authenticated access to Enterprise JavaBeans (EJB) files. When using the RMI connector, these logins might be requests for Java Management Extensions (JMX).

WEB_INBOUND

This login configuration handles logins for web application requests, which include 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 that is passed into the WEB_INBOUND login configuration might contain objects that are generated by the TAI.

DEFAULT

This login configuration handles 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

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 without a password.

Callback

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

Responsibility

Collects the password that is 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

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

Restriction: 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. You must enable security attribute propagation for both the outbound and inbound authentication.

You can enable the Security attribute propagation option for CSIv2 outbound authentication by completing the following steps:

1. Click Security > Global security.
2. Under Authentication, expand RMI/IIOP security and click CSIv2 outbound authentication.
3. Enable the Security attribute propagation option.

You can enable the Security attribute propagation option for CSIv2 inbound authentication by completing the following steps:

1. Click Security > Global security.
2. Under Authentication, expand RMI/IIOP security and click CSIv2 inbound authentication.
3. Enable the Security attribute propagation option.

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 a Lightweight Third Party Authentication (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)
  Important: 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 you do not validate this LTPA token, when present.
• A combination of any of the previously mentioned callbacks plus the callbacks[3] = new com.ibm.wsspi.security.auth.callback.WSTokenHolderCallback(Authz Token List:); callback.
  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. The 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, complete the following steps:

  1. Click Security > Global security.
  2. Under Authentication, click CSIv2 inbound authentication.

  A custom login module needs to handle custom serialization. For more information, see Security attribute propagation in the product documentation.

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.

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. 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 the application server must map the realm. For more information, see Configuring outbound identity mapping to a different target realm in the product documentation.

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

For more information, see Configuring outbound identity mapping to a different target realm in the product documentation.

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

Note: SWAM is deprecated in the application server Version 8.5 and will be removed in a future release.

This login configuration enables you to map an ID in an Lightweight Directory Access Protocol (LDAP) user registry to a System Authorization Facility (SAF) user ID

Note: SWAM is deprecated in the application server Version 8.5 and will be removed in a future release.

Processes login configuration requests for Web Services Security using identity assertion.

This login configuration is for Web Services Security Draft 13 JAX-RPC (Version 5.x) applications. For more information, see Identity assertion authentication method in the product documentation.

Processes 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.

Verifies an X.509 certificate with a certificate revocation list in a Public Key Cryptography Standards #7 (PKCS7) object.

This login configuration is for Version 6.0.x systems.

Verifies an X.509 certificate with a public key infrastructure (PKI) path.

This login configuration is for Version 6.0.x systems.

Processes login configuration requests for Web Services Security using digital signature validation.

This login configuration is for Version 5.x systems.

Verifies 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:

The custom property com.ibm.wsspi.wssecurity.auth.module.UsernameLoginModule.disableUserRegistryCheck can be configured for the JAAS UsernameToken login module. This property is an option for the Web Services Security UsernameToken JAAS login module, com.ibm.wsspi.wssecurity.auth.module.UsernameLoginModule. The property indicates that the login module should not perform a user registry check when processing an inbound username token.

Verifies an X.509 binary security token (BST) by checking the validity of the certificate and the certificate path.

This login configuration is for Version 6.0.x systems.

Processes 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. 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 Example: Customizing a server-side Java Authentication and Authorization Service authentication and logon configuration in the product documentation.

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

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

The com.ibm.ws.security.server.lm.ltpaLoginModule login module is predefined 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 Example: Customizing a server-side Java Authentication and Authorization Service authentication and logon configuration in the product documentation.