Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-16337

AM OOTB SDK cache settings Not working as expected.

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Not a defect
    • Affects Version/s: 6.5.2.3
    • Fix Version/s: None
    • Component/s: session
    • Labels:
    • Support Ticket IDs:

      Description

      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. 


      How to reproduce the issue

      My setup is as follows for the TEST.  
      AM Server on http://ashmanmmxx.example.com:8080/AM-6.5.2.3.  __ 
      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
      here: http://customers.example.com:8080/AM-6.5.2.3/XUI/#profile/details 

      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
      SAVE Changes!

      1. 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
        SAVE Changes!
      2. 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
        SAVE Changes!

      Now TEST

      1. Log the user into AM and copy the cookie into the curl command that follows:
      2. As an amadmin, confirm Session in AM Console
      3. Fire a date (time check), curl (to check Cache current VALUE!) and ldapsearch (to check DS current VALUE!)
      [ahale@ashmanMMXX bin]$ date
      Fri Jun  5 13:07:10 PDT 2020
      
      $ pwd
      /home/ahale/AM-6.5.2.3/opends/bin
      
      $ curl -k -s -X POST -H "Content-Type: application/json" -H "Accept-API-Version: resource=3.1, protocol=1.0" -H "iPlanetDirectoryPro:CYo9VucmLD8hmdX4x8xGZoxdUQQ.*AAJTSQACMDEAAlNLABxyU2Qrb2tSU3ZKYnZiVUdheHc3UGNRZE91bm89AAR0eXBlAANDVFMAAlMxAAA.*" http://customers.example.com:8080/AM-6.5.2.3/json/realms/root/realms/customers/sessions/?_action=getSessionProperties  
      
      {"am.protected.mail":"tina@example.com", 
      "AMCtxId":"05853d1b-7238-42e7-88c9-b8db0262264e-190702", 
      "am.protected.telephoneNumber":"1-800-678-5555", 
      "am.protected.lastName":"name"}
      
      $ ./ldapsearch --hostname ashmanMMXX --port 50389 --bindDN "cn=Directory Manager" --bindPassword cangetinam --baseDN "dc=openam,dc=forgerock,dc=org" --searchScope sub "(uid=tina)" '+' '*' | grep telephoneNumber
      telephoneNumber: 1-800-678-5555
      
      

            4.  Make a change to the telephoneNumber (not a multi-valued attr!) the DS side.

            5. Repeat step 3.  ldapsearch okay!  curl noway.

      [ahale@ashmanMMXX bin]$ date
      Fri Jun  5 13:14:58 PDT 2020
      
      
      $ ./ldapsearch --hostname ashmanMMXX --port 50389 --bindDN "cn=Directory Manager" --bindPassword cangetinam --baseDN "dc=openam,dc=forgerock,dc=org" --searchScope sub "(uid=tina)" '+' '*' | grep telephoneNumber
      telephoneNumber: 1-800-678-1111
      
      
      $ curl -k -s -X POST -H "Content-Type: application/json" -H "Accept-API-Version: resource=3.1, protocol=1.0" -H "iPlanetDirectoryPro:CYo9VucmLD8hmdX4x8xGZoxdUQQ.*AAJTSQACMDEAAlNLABxyU2Qrb2tSU3ZKYnZiVUdheHc3UGNRZE91bm89AAR0eXBlAANDVFMAAlMxAAA.*" http://customers.example.com:8080/AM-6.5.2.3/json/realms/root/realms/customers/sessions/?_action=getSessionProperties
      
       {"am.protected.mail":"tina@example.com",
      "AMCtxId":"05853d1b-7238-42e7-88c9-b8db0262264e-190702",
      "am.protected.telephoneNumber":"1-800-678-5555",
      "am.protected.lastName":"name"}
      
      

            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.

      Expected behaviour
      Cache is refreshed after 5 minutes, thus catching & reflecting any updates from the DS side.
      
      Current behaviour
      Cache is Not Updated, and the stale data is derailing expected workflow outcomes thereafter.
      The cache will store and use the old data until the session has been recreated 
      ie. session times out, abends, amadmin invalidates or user logs out and back-in.

      Work around

      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.

        Attachments

          Activity

            People

            • Assignee:
              jonthomas Jonathan Thomas
              Reporter:
              ashley.hale Ashley Hale
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: