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

Configuration LDAP accessed when users endpoint accessed

    XMLWordPrintable

    Details

    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 6.0.0, 6.0.0.1, 6.0.0.2, 6.0.0.3, 6.0.0.4, 6.0.0.5, 6.5.0, 6.0.0.6, 6.5.0.1, 7.0.0
    • None
    • Rank:
      1|hzxp0v:

      Description

      Bug description

      The /users endpoint (for the first time) cause access to the configuration directory related to delegation access.

      Now this may not be an issue in functionality but from a scalability issue it causes a lot of load to configuration directory (when a users endpoint is accessed). Now there is no such config LDAP activity from /authenticate or /session endpoint (if OPENAM-13330 is not hit)

      How to reproduce the issue

      1. Install AM, create a /external realm
      2. Authenticate to /external realm
      3. Access the users endpoint /users/<user> on this realm
      curl -s  \
       -k \
       --request GET \
       -H 'X-Requested-With: XMLHttpRequest' \
       --header "iplanetdirectorypro: <ssoToken>" \
       --header "Content-Type: application/json" \
         "$URL/openam/json/users/$user?realm=/test"
      
      1. Check that the Config LDAP access log and notice the first time the users endpoint it access, this is accessed.
      Expected behaviour
      Reduce access to this config store on this delegation access
      
      Current behaviour
      The first time the /json/users/<user> for this session is called the delegation LDAP access is done. Check ldap access logs
      
      {"eventName":"DJ-LDAP","client":{"ip":"xx.xx.xx.xx","port":49240},"server":{"ip":"xx.xx.xx.xx","port":10389},"request":{"protocol":"LDAP","operation":"SEARCH","connId":1,"msgId":734,"dn":"ou=default,ou=default,ou=OrganizationConfig,ou=1.0,ou=sunEntitlementIndexes,ou=services,o=sunamhiddenrealmdelegationservicepermissions,ou=services,dc=openam,dc=forgerock,dc=org","scope":"sub","filter":"(&(|(sunxmlKeyValue=hostindex=://dc=openam,dc=forgerock,dc=org)(sunxmlKeyValue=hostindex=://ou=services,dc=openam,dc=forgerock,dc=org)(sunxmlKeyValue=hostindex=://o=external,ou=services,dc=openam,dc=forgerock,dc=org)(sunxmlKeyValue=hostindex=://))(|(sunxmlKeyValue=pathindex=/sunamrealmservice)(sunxmlKeyValue=pathindex=/sunamrealmservice/\\2A)(sunxmlKeyValue=pathindex=/sunamrealmservice/\\2A/default)(sunxmlKeyValue=pathindex=/)))","attrs":["sunKeyValue","sunxmlKeyValue"]},"transactionId":"6b353bad-dc44-4034-b82c-532159e34a23-6223","response":{"status":"SUCCESSFUL","statusCode":"0","elapsedTime":0,"elapsedTimeUnits":"MILLISECONDS","nentries":1},"timestamp":"2019-03-10T14:29:29.199Z","_id":"6b353bad-dc44-4034-b82c-532159e34a23-6225"}
      ....
      {"eventName":"DJ-LDAP","client":{"ip":"xx.xx.xx.xx","port":49244},"server":{"ip":"xx.xx.xx.xx","port":10389},"request":{"protocol":"LDAP","operation":"SEARCH","connId":3,"msgId":726,"dn":"ou=default,ou=default,ou=OrganizationConfig,ou=1.0,ou=sunEntitlementIndexes,ou=services,o=sunamhiddenrealmdelegationservicepermissions,ou=services,dc=openam,dc=forgerock,dc=org","scope":"sub","filter":"(&(|(sunxmlKeyValue=hostindex=://dc=openam,dc=forgerock,dc=org)(sunxmlKeyValue=hostindex=://ou=services,dc=openam,dc=forgerock,dc=org)(sunxmlKeyValue=hostindex=://o=external,ou=services,dc=openam,dc=forgerock,dc=org)(sunxmlKeyValue=hostindex=://))(|(sunxmlKeyValue=pathindex=/sunamrealmservice/1.0)(sunxmlKeyValue=pathindex=/sunamrealmservice/1.0/organizationconfig)(sunxmlKeyValue=pathindex=/sunamrealmservice)(sunxmlKeyValue=pathindex=/)))","attrs":["sunKeyValue","sunxmlKeyValue"]},"transactionId":"6b353bad-dc44-4034-b82c-532159e34a23-6226","response":{"status":"SUCCESSFUL","statusCode":"0","elapsedTime":1,"elapsedTimeUnits":"MILLISECONDS","nentries":1},"timestamp":"2019-03-10T14:29:29.205Z","_id":"6b353bad-dc44-4034-b82c-532159e34a23-6228"}
      

      Issue is that these access looks the same and ideally should be cached. Or more like saying as the session is belonging to the same user, the same user should not be causing delegation checks on themselves.

       

      Work around

      • Code analysis

      Something similar from 6.0 -> 7.0

      at com.sun.identity.entitlement.opensso.DataStore.searchPrivileges(DataStore.java:705)
       at com.sun.identity.entitlement.opensso.DataStore.search(DataStore.java:645)
       at com.sun.identity.entitlement.opensso.OpenSSOIndexStore$SearchTask.run(OpenSSOIndexStore.java:642)
       at com.sun.identity.entitlement.SequentialThreadPool.submit(SequentialThreadPool.java:38)
       ...
       at com.sun.identity.entitlement.Evaluator.evaluate(Evaluator.java:196)
       at com.sun.identity.policy.PolicyEvaluator.getPolicyDecision(PolicyEvaluator.java:773)
       at com.sun.identity.policy.PolicyEvaluator.getPolicyDecision(PolicyEvaluator.java:723)
       at com.sun.identity.delegation.plugins.DelegationPolicyImpl.isAllowed(DelegationPolicyImpl.java:550)
       at com.sun.identity.delegation.DelegationEvaluatorImpl.isAllowed(DelegationEvaluatorImpl.java:219)
       at com.sun.identity.idm.server.IdServicesImpl.checkPermission(IdServicesImpl.java:2570)
       at com.sun.identity.idm.server.IdServicesImpl.getMemberships(IdServicesImpl.java:913)
       at com.sun.identity.idm.AMIdentity.getMemberships(AMIdentity.java:1227)
       

      Most of the delegation check seems to be due to getMemberships()

        Attachments

          Activity

            People

            Unassigned Unassigned
            chee-weng.chea C-Weng C
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated: