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

Inefficient LDAP Search initiated by getRealmFromAlias() call as part of login process

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 13.5.1, 14.1.1, 5.5.1
    • Fix Version/s: 6.0.0, 5.5.2
    • Component/s: None
    • Labels:
    • Target Version/s:
    • Sprint:
      AM Sustaining Sprint 47
    • Story Points:
      2
    • Needs backport:
      Yes
    • Support Ticket IDs:
    • Needs QA verification:
      No
    • Functional tests:
      No
    • Are the reproduction steps defined?:
      Yes and I used the same an in the description

      Description

      Bug description

      As part of login flow, I have observed that a call to getRealmFromAlias() occurs in RealmContextFilter in an attempt to find an entry based on a DNS alias. This will subsequently perform a search of the configuration store - via SMSLDAPObject#searchOrganizationNames()

      The filter that gets constructed in this method contains a search for objectclass=sunRealmService objects (which makes sense). However, the search also includes in this filter a search for objectClass=sunServiceComponent objects, I believe this is to search the 'ou=services,%ROOT_SUFFIX% entry" :

      filter="(|(&(objectclass=sunRealmService)(&(|(sunxmlKeyValue=sunidentityrepositoryservice-sunOrganizationAliases=openam.test.com)(sunxmlKeyValue=sunOrganizationAliases=openam.test.com))))(&(objectclass=sunServiceComponent)(&(|(sunxmlKeyValue=sunidentityrepositoryservice-sunOrganizationAliases=openam.test.com)))))

      However, this search across all objectclass=sunServiceComponent entries seems to cause problems for any customers with a large number of agents (>5000) configured as the resulting query may fail due to the large number of entries it finds.

      # The LDAP search request failed: 11 (Administrative Limit Exceeded)
      # Additional Information:  This search operation has checked the maximum of 5000 entries for matches

      If the getRealmFromAlias() call fails this then breaks down the login process and the user is presented with an 'Internal Server Error" and is unable to login. 

      Ideally we need to limit this realm/organization name search to not include all sunServiceComponent entries (which will include the likes of agent config entries etc) so that this issue cannot occur during the login process.

      How to reproduce the issue

      1. Setup an Open-DJ (DS-5.0.0) to be used an external config store - configure a non 'Directory Manager' account to use as per instructions here: https://backstage.forgerock.com/docs/am/5.1/install-guide/#prepare-ext-stores 
      2. Setup AM (in this instance I used version 14.1.1) and point this at the external config store during the configuration. (This store can also be used as the user store for convinience)
      3. Login to AM and create a new realm named 'test' - this is required for the OAuth2 clients generated in the following script...
      4. ...Generate 5000 OAuth2 clients - for convenience you may used the attached script 
      5. Restart AM and attempt to login to the UI

      Tested on 14.1.1 and 5.5.1 - However, it is likely to also affect older versions as this area of the code has remained unchanged for some time.

      Expected behaviour
      User is presented with the AM login page
      
      Current behaviour
      User is presented with an "Internal Server Error" and is unable to login.
      

      Work around

      During customer investigation it was noted that if the sunxmlkeyvalue index was configured for the DJ configuration this would resolve the issue. But the search filter generated here still appears to be rather broad for what it is attempting to search for (a realm), and so should probably be optimised. 

      Code analysis

      As mentioned - the filter in question is generated in SMSLDAPObject.java within the searchOrganizationNames() method.

       

       

        Attachments

          Activity

            People

            • Assignee:
              adam.heath Adam Heath
              Reporter:
              adam.heath Adam Heath
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: