|
Problem |
A custom jaas_login module, which is the first login
module in
system.WEB_INBOUND, isn't invoked when a user ID/password is cached in
AuthCache.
The application developer is seeking a way to invoke the custom_login
module even the user id/password is cached. |
|
Cause |
This is working as designed.
The purpose of Authentication Cache is to alleviate the volume of
accessing a user registry (such as an LDAP server). It stores the Subject
which can be searched by user ID/password, token, and so on. The stored
password is encrypted by a one way hash algorithm.
When an HTTP request comes in and a target URL is protected, first, the
WebContainer invokes the login module in the ContextManager (which is not
a jaas_login module). It searches AuthCache data by using user id and
password. If cached data is available, it extracts the Subject by using
the cached data. Since the cache key is constructed by using the user ID
and the password, user ID and password validation is done by using the
cache data, therefore the login module doesn't invoke any JAAS login
module.
It does not matter whether it is a custom login module or one of the
default login modules, such as wsMapDefaultInboundLoginModule.
Summary:
- The first login is authenticated by JAAS login module.
- The custom JAAS module is invoked.
- The second login doesn't invoke jaas_login module since the login
module can extract the data from the cache.
|
|
Solution |
The only way to change this behavior and let WebSphere
Application Server
invoke the jaas_login module all the time is to disable the cache by
adding the following custom property in the JVM:
com.ibm.websphere.security.util.authCacheEnabled=BasicAuthDisabled
|
|
|
|
Cross Reference information |
Segment |
Product |
Component |
Platform |
Version |
Edition |
Application Servers |
Runtimes for Java Technology |
Java SDK |
|
|
|
|
|
|
|