The support case was opened because a user's profile was not reflecting a role change that was propagated the night before to DS. Ideally, an Access Request would have been submitted and fulfilled so by the time user logs in again, they would have the new Attribute VALUE! so as to gain appropriate access to resources thereafter. Once the AM Server had been restarted, the current profile would be used and in the current state, which is not practical. Furthermore, subsequent changes to the attribute would not be reflected when testing because we find the old value in the IdRepo logs and when firing a curl command to getSessionInfo. So something is off in cache management and they DO NOT want to disable caching at the time of this writing.
Using KBA FAQ: Caching in AM/OpenAM and DOC 8.4.3. Tuning Caching we continued to troubleshoot various ways to get cache updated and in sync as desired. At the Identity Store level we disabled Global cache (for CFG and USR Stores) via com.iplanet.am.sdk.caching.enabled=false and set com.sun.identity.idm.cache.enabled=true.
After several attempts adjusting settings, things still were not working as expected. Support went back to the basic OOTB settings to verify the behavior and finds cache not getting updated at all (until an AM server restart).
Unless we did something wrong or we're missing something in the following steps, it seems AM OOTB SDK cache settings are Not working as expected. And note! Originally, we learned their DS had PSEARCH disabled but we tried with it enabled and testing locally finds that DOES NOT make a difference as PSEARCH is still enabled on the embedded DS used below.
My setup is as follows for the TEST.
AM Server on http://ashmanmmxx.example.com:8080/AM-22.214.171.124. __
Created a realm for 'customers' using ldapService chain for AuthN, added a few users and will work with user:tina below. This server is where we will be making the change in Apache Directory Studio to the embedded DS. Also, this server is where we will fire the curl and ldapsearch commands to confirm the cache is not being refreshed or updated.
The user/client connects to AM Server from another VM ashman2020 and lands on their User Profile page.
So if all is setup properly, the user can login and view their user profile
0. Cache control is NOT enabled by default OOTB, so set the following parameters in the console and restart AM.
CONFIGURE > SERVER DEFAULTS > SDK, Time To Live Configuration TAB!
Note: pop-ups do not tell us if these are Hot-Swap: Yes or No, thus assuming No because testing without an AM restart does not change this behavior.
Cache Entry Expiration Enabled =ON com.iplanet.am.sdk.cache.entry.expire.enabled
User Entry Expiration Time =5 com.iplanet.am.sdk.cache.entry.user.expire.time
Default Entry Expiration Tim =5 com.iplanet.am.sdk.cache.entry.default.expire.time
- Add the Session Property Whitelist Service to the REALM! to broadcast these attributes
(Noting: AMCtxId is present by default OOTB)
Whitelisted Session Property Names (4):
am.protected.mail AMCtxId am.protected.telephoneNumber am.protected.lastName
- MAP the DS attr NAME! to your chosen Session Property NAME! under:
REALM! > Authentication > Settings, Post Authentication Processing TAB!
User Attribute Mapping to Session Attribute (3):
sn|lastName telephoneNumber|telephoneNumber mail|mail
- Log the user into AM and copy the cookie into the curl command that follows:
- As an amadmin, confirm Session in AM Console
- Fire a date (time check), curl (to check Cache current VALUE!) and ldapsearch (to check DS current VALUE!)
4. Make a change to the telephoneNumber (not a multi-valued attr!) the DS side.
5. Repeat step 3. ldapsearch okay! curl noway.
6. Refresh the User Profile page to confirm the same from AM.
7. Wait for SDK TTL time outs to elapse (over 5 min) and repeat step 3, go to lunch (or wait a while like 31 or 61 minutes later to test again). As long as the Session has not expired, the cache will still be stale.
Restart the AM Server or disable global cache to perform a round trip read from DS (sans cache!).
After the user's session expires they have to login again, thus creating a new Session with the user's current state pulled correctly from DS! But for long lived user sessions, if they refresh a page AM should be picking up any changes. Originally, we thought this was because PSEARCH was disabled on the customer's DS, but is not disabled when testing above.