You are correct, if you are not using the group for authorization checking, then the attributes cache does not come into play here. However; the search cache does and it takes 20 minutes (default cache timeout) after the last search for it to clear out of the cache before a change to the user on the backend LDAP server will be seen by the LDAP user repository.
Let me know if you have any more questions.
Original Message:
Sent: Wed March 15, 2023 01:04 PM
From: Maik Weber
Subject: Federated repository - User search filter with group membership, authentication and caching
Hi Jesse,
I would like to follow up on that question. In the meantime, I have been testing the scenario again:
- User "new_user" is not member of the access group "app-access"
- User "new_user" tries to access application and authenticates but fails -- error CWWIM4537E -- that's correct behaviour
- User is added to access group "app-access"
- Directly after, user "new_user" retries to authenticate but still fails -- error CWWIM4537E
- After around 20 minutes, user "new_user" retries again and authentication is successful
You mentioned that the LDAP search query and its result are cached. Is that also true in case of authentication/login attempts?
The access group is not used for authorization, meaning, it is not used / configured in J2EE security roles of the application. I understand that in this case, the "member" attributes of the group are cached and used for verification check. This avoids to look up the group members with every access to the application. Here the default attribute caching of 20 minutes would apply, and user would not be able to access the application even authentication is successful. But as said, this should not apply in our scenario just for authentication / login.
Greetings
Maik
------------------------------
Maik Weber
Original Message:
Sent: Tue February 21, 2023 03:50 PM
From: JESSE VAN HILL
Subject: Federated repository - User search filter with group membership, authentication and caching
Hi Maik -
So there are several things going on here.
When you log in, WAS is going to try to find the user using the search filters you've defined and the login name that was supplied. That is the LDAP search you outlined above. If you haven't searched for that user before (or in the last 20 mins) that should result in a call out to the LDAP server because that search and its results are not in the LDAP search cache.
It appears this is what occurs for you, you find the user. I am guessing later in your packet capture trace you will see a bind with the new_user DN. So far so good. Where it probably goes wrong is when it searches for group membership for authorization. I am assuming that group member is defined via a "member" attribute on your LDAP groups. Those attributes get stored in the LDAP attribute cache under the group. Since all your users *must* be a member of that same group, that probably is constantly being placed in the cache (almost immediately after the entry expires) since that group will be looked up for any user during group membership lookup.
So long story short, the group membership "member" attributes have probably been loaded into the attributes cache during another (successful) login by another user. Until they fall out of the cache, "new_user" won't be recognized as part of that group.
------------------------------
JESSE VAN HILL
Original Message:
Sent: Tue February 21, 2023 03:33 PM
From: Maik Weber
Subject: Federated repository - User search filter with group membership, authentication and caching
Hi Jesse,
many thanks for your detailed answer.
If WebSphere uses the attributes cache to store group membership, why does a search for the new user in WebSphere ISC via Manage users returns the correct user, but an LDAP lookup during authentication does not?
With LDAP tracing enabled, you can see that WebSphere is performing a LDAP search using the defined search filter for users
(&(uid=new_user)(groupMembership=cn=app-access,ou=IDM,ou=groups,o=base,c=DE))
Yes, the check on groupMembership attribute is part of LDAP search filter, but that should be evaluated on LDAP server side, not at WebSphere. I could imaging that WebSphere caches the result of a previous LDAP lookup using this specific filter, when the user was not yet member of the group and therefore LDAP server returned no result. But again, if it is not separated, this would mean that a search via "Manage users" in ISC would also not return the user as long as the cache entry is not invalidated.
Does it make sense or do I have a complete missunderstanding?
Greetings
Maik
------------------------------
Maik Weber
Original Message:
Sent: Mon February 20, 2023 02:35 PM
From: JESSE VAN HILL
Subject: Federated repository - User search filter with group membership, authentication and caching
Hi Maik.
There are several layers of caching you are interacting with here. The authentication cache is for successful authentications. Since you are adding a new user, this cache should not be your problem as it only stores successful authentication results.
The federated LDAP registry also has two caches. There is a attributes cache and a search results cache. Your issue is probably with the attributes cache. A previous login probably did a group membership lookup for the "app-access" group. Those results will stay in attributes cache until they expire - the default I believe is 20 mins. After 20 minutes, the entry in the cache should expire and then your next lookup will result in a fresh lookup to LDAP (which will now be cached for the next 20 mins).
You can test this by disabling the attributes cache, but be aware that I wouldn't recommend running like this as it can be a large performance hit.
You can alternatively test this by calling the "clearIdMgrRepositoryCache" wsadmin command prior to logging in for the first time. This also has a performance impact as it clears all caches for the LDAP registry.
- https://www.ibm.com/docs/en/was-nd/8.5.5?topic=commands-clearidmgrrepositorycache-command
Another alternative that might be more targeted would be to use "-clearCache" option of the "getMembersOfGroup" or the "getMembershipOfGroup" commands.
- https://www.ibm.com/docs/en/was-nd/8.5.5?topic=commands-getmembersofgroup-command
- https://www.ibm.com/docs/en/was-nd/8.5.5?topic=commands-getmembershipofgroup-command
I hope this helps.
------------------------------
JESSE VAN HILL
Original Message:
Sent: Thu February 16, 2023 03:23 PM
From: Maik Weber
Subject: Federated repository - User search filter with group membership, authentication and caching
Hi,
I have a question to the following scenario:
Customer is using a group to manage access to a set of applications running on WebSphere.
Therefore, in the federated repository configuration, the LDAP search filter for user lookup is set like
(groupMembership=cn=app-access,ou=IDM,ou=groups,o=base,c=DE)
(at Security > Global Security > Federated repositories/Configure > Repository > Federated repositories entity types to LDAP object classes mapping > PersonAccount > Search filter)
As a result, the user must be a member of the group "app-access" so that WebSphere is able to look up the user.
Users who are not member of the group are not allowed to authenticate and therefore not able to access the applications.
This setup is working fine except for one issue.
If you add a new user to the group "app-access", the new user is not able to authenticate immediately. Even after several minutes, WebSphere still prints the following error in SystemOut:
SECJ0369E: Authentication failed when using LTPA. The exception is com.ibm.websphere.wim.exception.PasswordCheckFailedException: CWWIM4537E No principal is found from the 'new_user' principal name..
However, if you use the ISC at Users and Groups > Manage users and search for the userid "new_user", the user can be found.
In short:
== User is not member of the access group "app-access"
1. User "new_user" tries to access application and authenticates but fails -- error CWWIM4537E -- that's correct behaviour
2. Lookup of userid in ISC (Users and Groups > Manage users) also returns no result -- that's correct behaviour
== User is added to access group "app-access"
3. After several minutes, user "new_user" tries to access application again but authentication still fails -- error CWWIM4537E
4. But lookup of userid in ISC (Users and Groups > Manage users) returns specific user
My understanding was that the LDAP user lookup is not cached for authentication, at least not for failed authentications. But seems that I was wrong.
What caching is involved, and how can check the caching time?
It sounds to me like an issue similar to https://www.ibm.com/support/pages/apar/PK53155
Greetings
Maik
------------------------------
Maik Weber
------------------------------