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

Privilege evaluation slow when a delegated user has a lots of group members



    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 13.5.0, 13.5.1, 14.0.0, 14.5.0, 14.5.1, 5.5.1
    • None
    • delegation, performance, sms
    • None


      Bug description

      When there are a lot of delegated admin user have a lot of groups, the AM privilege evaluation is excessive and can be slow. This can be extremely slow when the
      users have a lot of groups and these especially if these groups not not-existents (especially if more than 1 datastore and realms exists).

      The PrivilegeEvaluator does evaluation on sets of privileges and there if the Delegation policy group subject is to be matched to the "user", the user's group members will be matched. How due to the way AMIdentity works it will compare the group physical LDAP DN with this privilege subject LDAP DN. Now cost is avoided by the DNCache to cache any known groups.

      However, when there is a lot of groups member for the user that may be not-existent, these are not cached and there may be LDAP activity to evaluate this.

      Although by itself, the delegation evaluation looks fine even if it could take 4 secs (for non-existent 1000 groups). The 2nd issue is that the XUI and Jato UI, is code to query may query things a lot more... For example

      a) /global-config/realms?_queryFilter=true will run thru every delegation evaluation per realm. So if the above is slow it is compound by the number of realms to display the overview page

      b) Similarly for the JATO "privilege" screen, it seems that JATO tabs, does some privilege evaluation for each tab and so this is also make it slow.

      How to reproduce the issue

      Testcase as in OPENAM-12333. The key is 2 realms and one realm does not have groups found on it. With many realms too.

      Expected behaviour
      Better performance for groups (and if there is not present)
      Current behaviour
      Slow privilege evaluations. 

      Work around

      Do not have large groups or at least make sure all the group the user is a member of is found in all the realms's datastore.

      Now, if there is large groups and if the group memberships is used (w/o using the "Group membership attribute" the code may iterate to get all the members thru say "uniquemember".. ie slow.What i am trying to say is that large groups we tuned DNCache and also use Group membership attributes to try to bring thngs down but there's some bottleneck too.

      Code analysis

      AMIdentity.isMember and .equals() when checking group member might not be go to LDAP and not dncache-able if these is not in the datastore. So if there is alot of these it may slow down things a lot


          Issue Links



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