File name: usec_sysjaas.html
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, complete
the following steps:
- Click Security > Secure administration, applications, and infrastructure.
- Under Authentication, click Java Authentication and Authorization
Service > System logins.
Read the Java Authentication and Authorization Service documentation
before you begin defining additional login modules for authenticating
to the application server security runtime. Do not remove the following
system login modules:
- RMI_INBOUND
- WEB_INBOUND
- DEFAULT
- RMI_OUTBOUND
- SWAM
- wssecurity.IDAssertion
- wssecurity.signature
- wssecurity.PKCS7
- wssecurity.PkiPath
- wssecurity.UsernameToken
- wssecurity.X509BST
- LTPA
- LTPA_WEB
- DESERIALIZE_ASYNCH_CONTEXT
RMI_INBOUND, WEB_INBOUND, DEFAULT
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. A password
of null is allowed, and is used to support 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 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:
- Click Security > Secure administration, applications, and infrastructure.
- Under Authentication, expand RMI/IIOP security and click CSIv2
outbound authentication.
- Enable the Security attribute propagation option.
You can enable the
Security attribute
propagation option for CSIv2 inbound authentication by completing
the following steps:
- Click Security > Secure administration, applications, and infrastructure.
- Under Authentication, expand RMI/IIOP security and click CSIv2
inbound authentication.
- 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:
- Click Security > Secure administration, applications, and infrastructure.
- Under Authentication, click CSIv2 inbound authentication.
A custom login module needs to handle custom serialization.
For more information, see "Security attribute propagation" in the
information center.
In addition to the callbacks that are 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
- 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 cookie 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 if present contains the application
name and the redirected Web address.
- Callback
callbacks[7] = new WSRealmNameCallbackImpl("Realm Name: ", <default_realm>);
- Responsibility
- Collects 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.).
If you want to use security attribute propagation
with the WEB_INBOUND login configuration, you can enable
Web inbound
security attribute propagation option on the Single sign-on panel.
- Click Security > Secure administration, applications, and infrastructure.
- Under Authentication, expand Web security and click Single
sign-on (SSO).
- Select the Web inbound security attribute propagation option.
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:
- 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.
For
more information on adding a hashtable containing well-known and well-formed
attributes used by the application server as sufficient login information,
see "Configuring inbound identity mapping" in the information center.
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, complete the following steps:
- Click Security > Secure administration, applications, and infrastructure.
- Under Authentication, expand RMI/IIOP security and click 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 the application server
Version 5.1.1 or later (or 5.1.0.2 for z/OS) 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 or later 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,
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 mapping to a different target realm" in the information center.
- 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.
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 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
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 are processed after this login module acts on the new Subject
contents.
For more information, see "Configuring outbound mapping to a different
target realm" in the information center.
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, the application server cannot send requests
from server to server. In this case, you must use LTPA.
Note: The SWAM login configuration is deprecated and will
be removed in a future release.
wssecurity.IDAssertion
Processes login configuration requests for Web services
security using identity assertion.
This
login configuration is for Version 5.x applications. For more information,
see "Identity assertion authentication method" in the information
center.
wssecurity.IDAssertionUsernameToken
Processes login configuration requests for Web services
security using identity assertion.
This
login configuration is for Version 6.x 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 Version 6.x systems.
wssecurity.PkiPath
Verifies an X.509 certificate with a public key infrastructure
(PKI) path.
This
login configuration is for Version 6.x systems.
wssecurity.signature
Processes login configuration requests for Web services
security using digital signature validation.
This
login configuration is for Version 5.x systems.
wssecurity.UsernameToken
Verifies basic authentication (user name and password).
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.
wssecurity.X509BST
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.
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 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 information center.
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 "Example: Customizing a server-side Java Authentication and Authorization
Service authentication and logon configuration" in the information
center.
DESERIALIZE_ASYNCH_CONTEXT
Processes login requests for asynchronous beans.
The DESERIALIZE_ASYNCH_CONTEXT configuration is used for asynchronous
beans only. The scheduler utilizes 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.
CAUTION:
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.
|
