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

AMIdentitySubject policy evaluation not cache when a lot of groups and datastore is use with delegated admin



    • Rank:
    • AM Sustaining Sprint 48, AM Sustaining Sprint 49
    • 3
    • No
    • Yes
    • No
    • Yes and I used the same an in the description


      Bug description

      When using a full access delegated admin and this user has many groups, there is slowness to access the console for realm related URL. It seems that there is a lot of activity evaluating Group isMember checking with the directory. The delegation evaluation seems to acause a lot of work doing group related checking.

      How to reproduce the issue

      1. DataStore (AD, AD2 (can reuse AD but with a unique name ) and one embedded
        (All with DnCache=15000 enabled (does not make a difference).
        Created an AD with 1000 GROUPS

      For ($i=2; $i -lt 1000; $i++)

      { $text = "TestGroup2018-$i" New-ADGroup -name $text -groupscope Global }
      1. Create amuser1 and amuser2.
      2. Create an AMGroup with FULL admin privilege
      3. Assign both users to AMGroup
      4. Assign amuser1 with TestGroup2018-* while amuser2 only has AMGroup
      5. Test access to XUI, the access look fine
      6. Add "ismemberof" and "member" to the LDAP User attributes and
        amuser1 access ALL the GROUPS but amuser2 is fine.
        Now this test we make sure the the datastore DOES not have this user
      7. You may want to create 2 subrealms as it would seems this may makes things even slower.

      Observation is that access to /global-config/realms?_queryFIlter=true is slow (from the network trace) and many activity the evaluation group isMember/getDN(). Note that amuser2 which has not much group tied to it as well as amadmin is reasonable in console access speed.

      You can try creating a new realm using this large group amuser1 and see it very slow (and doing a lot of evaluation)

      Expected behaviour
      Accessing the console should be acceptable for large groups
      Current behaviour
      Slow access to when there login in with a delegated admin that has 1000-2000 groups under it. In fact, creating a new realm using this delegated admin is magnitude orders slower.

      Work around

      Limit the number of groups per delegated admin.

      Code analysis

      The AMIdentity.equals() when it is a IdType:GROUP will call out to getFullyQualifiedName() to get the actual DN for resolved the group DN for matching. This is a physical DN retrieval.

      It also seems that AMIdentitySubject is used for Delegated admin and the fix similar to Subject evaluation cache (OPENAM-10931) is not implemented to AMIdentitySubject so repeated evaluation is not cached. Test suggested this may cut down a lot of redundant evaluation (if repeated access). So similar fix is needed here.

      In this test DNCache is enabled and true (large) to avoid repeated DN but if large groups is for this user. This does not cut down things much.


          Issue Links



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