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

Session property update is not batched and do per LDAP operation per property



    • Bug
    • Status: Closed
    • Major
    • Resolution: Duplicate
    • 5.5.1, 6.0.0,,,,,, 6.5.0,,, 6.5.1
    • None
    • None
    • Rank:


      Bug description

      Since the change to CTS for stateful session, the API to set extra properties to the session using the API SSOToken.setProperty() make an CTS update per call. This is a expensive and slow call as is does a round-trip to the CTS (which manifest as an LDAP modify).

       Now there are many of these type of calls in AM, and in fact one cannot escape or workaround this issue since it is used in Post Authentication plugin and all the other AM authentication code that does a setProperty() (for an existing session that is already build)

      This also applies to the REST call updateSessionProperties which will issue one LDAP operation per property change

      How to reproduce the issue

      1. Install a PAP with a for loop that does token.setProperty(key,value) say 100 times. and you will see that there is 100 LDAP modify on the LDAP logs.
      2. or setup a session whitelist for a set properties and use the REST updateSessionProperties to update the session.
      • In in a realm, create Session Property Whitelist service
      • Create more session property names
      • Create a session
      • Get the session property
        curl -s \
         -k \
         --request POST \
         -H 'X-Requested-With: XMLHttpRequest' \
         --header "iplanetdirectorypro: $tokenID" \
         --header "Content-Type: application/json" \
      • Update
        curl -s \
         -k \
         --request POST \
         -H 'X-Requested-With: XMLHttpRequest' \
         -d "
         \"EXT-KEY1\":\"EXT-VALUE-1-$$\",\"EXT-KEY3\":\"EXT-VALUE-3\"}" \
         --header "iplanetdirectorypro: $tokenID" \
         --header "Content-Type: application/json" \
      Expected behaviour
      Reduced overhead. Or there is a bulk session property updater
      Current behaviour
      Each token.setProperty() causes a LDAP traffic as long one uses the SessionService to get the service and use the setProperty

      Work around

      None. Tune the CTS performance (as there is increased traffic). Otherwise put to use needed stuff in one session key and the value could be say some key=value pair (CSV, or JSON)

      Code analysis

      SessionService.getSession(...) return a CTSSession that will always goto CTS and update the LDAP Store. In fact any SessionMutator in AM does that unless it is done during Session creation time.




          Issue Links



              Unassigned Unassigned
              chee-weng.chea C-Weng C
              0 Vote for this issue
              5 Start watching this issue