System login configuration entry settings for JAAS

 

To specify a list of JAAS system login configurations...

administrative console | Security | Global security | JAAS configuration | System logins

Read the JAAS documentation before you begin defining additional login modules for authenticating to the WAS security run time. Do not remove the following system login modules:

RMI_INBOUND, WEB_INBOUND, DEFAULT

Process inbound login requests for RMI, Web applications, and most of the other login protocols. These login configurations are used by WAS V5.1.1 and later.

RMI_INBOUND

The RMI_INBOUND login configuration handles logins for inbound RMI requests. Typically, these logins are requests for authenticated access to EJB files. Also, these logins might be JMX requests when using the RMI connector.

WEB_INBOUND

The WEB_INBOUND login configuration handles logins for Web application requests, which includes servlets and 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 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 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 WAS 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 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.

 

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.

In system login configurations, WAS 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:

  • 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, WAS maps the certificate to a user name. This callback is used by any login type that establishes trust using 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 an single signon (SSO) or downstream login. Any time a request originates from a WAS, instead of a pure client, the LTPA token typically flows to the target server. For single signon (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 WAS 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 in order for this to be successful. There is a possible security exposure 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,

    WAS uses the NameCallback and the token holder, which contains all of the propagated attributes, to deserialize most of the objects. WAS uses the NameCallback 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 Authentication protocol > CSIv2 Inbound authentication.

    Custom serialization needs to be handled by a custom login module. For more information, see "Security attribute propagation".

In addition to the callbacks defined previously, the WEB_INBOUND login configuration only can contain the following additional callbacks

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 one cannot remove these predefined login modules.

  • com.ibm.ws.security.server.lm.ltpaLoginModule

    This login module 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

    • 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 is present, the login module deserializes the byte token objects and regenerates the serialized Subject contents. The java.util.Hashtable takes precedence over all of the other forms of login. Be careful to avoid duplicating or overriding what WAS might have propagated previously. By specifying a java.util.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. Failure to validate the LTPA token presents a security risk.

    For more information on adding a Hashtable containing well-known and well-formed attributes used by WAS as sufficient login information, see "Configuring inbound identity mapping".

RMI_OUTBOUND

Processes 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 > Global security. Under Authentication, click 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 WAS V5.1.1 or later (or 5.1.0.2 for z/OS) communicates with a v5.x Application Server, then the V5.1.1 Application Server sends the authentication information only, using an LTPA token, to the V5.x Application Server. However, if WAS V5.1.1 or later communicates with a v5.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. 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 WAS 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 one 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 by 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

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 SWAM is used as the authentication method.

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

wssecurity.IDAssertion

Processes login configuration requests for Web services security using identity assertion. This login configuration is for v5.x systems.

wssecurity.PKCS7

This login configuration is for v6.x systems.

wssecurity.PkiPath

This login configuration is for v6.x systems.

wssecurity.signature

Processes login configuration requests for Web services security using digital signature validation. This login configuration is for v5.x systems.

wssecurity.UsernameToken

This login configuration is for v6.x systems.

wssecurity.X509BST

This login configuration is for v6.x systems.

LTPA_WEB

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 "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 WAS V5.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 "Customizing a server-side Java Authentication and Authorization Service authentication and login configuration" in the documentation.


 

See Also


Java Authentication and Authorization Service
Security attribute propagation

 

Related Tasks


Configuring outbound mapping to a different target realm
Configuring inbound identity mapping

 

See Also


Example: Customizing a server-side JAAS authentication and login configuration
Configuration entry settings for Java Authentication and Authorization