jsf-2.2open-libertyj-security-checkltpa

JSF user logs in successfully even after user account was locked by LDAP


I use JSF 2 deployed on Liberty 22.0.0.6 server.

My FORM based authentication is against LDAP using j_security_check. It is working and my user can log in/authenticate and get LTPA2 token back. And logout functionality works as well.

However, I notice the following

  1. user logs in successfully
  2. user logs out and is sent back to log in page - as expected
  3. If user attempts to log in with incorrect password, she is asked to go back to login page and provide correct credentials - as expected
  4. Repeat step 3
  5. Repeat step 3. On 3rd invalid attempt, LDAP locks the user account for 30 min
  6. User attempts to log in again before LDAP unlocks account, this time with correct credentials, and succeeds - THIS SHOULD NOT HAPPEN

I would expect that in step 6, user should not be allowed to log in even though she provided correct credentials, because LDAP has locked the account for 30 min in step 5.

Being new to Liberty server and JSF, I'm having difficulties understanding this. Is LTPA token being casheed somewhere and how to find that out?

Based on my reading, I think that the caching is happening in Liberty server, not in JSF app.


Solution

  • Check this page Configuring the authentication cache in Liberty. There is a auth cache in Liberty with default timeout of 600s.

    Quoting the page:

    Any change that is made to the user registry configuration in the server.xml file clears the authentication cache. However, if changes are made to an external user registry, such as LDAP, the authentication cache is unaffected.

    So in your case, Liberty doesnt know that the user account has been locked out and if it is within timeout, after successful authentication it is reusing credentials from the cache.

    You can either:

    <authentication id="Basic" cacheEnabled="false" />
    
     <authCache timeout="5m"/>
    

    What you will choose depends on your security requirements. I'd strongly avoid disabling cache in general, and if lowering timeout is not sufficient for you, you would have to write a service that would clear the cache on demand. But be aware that it clears the whole cache.