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

REST OAuth2 creation triggers objectClass=* search



    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 12.0.2, 14.1.0
    • 12.0.5, 13.5.2, 6.0.0, 14.1.2, 5.5.2
    • oauth2, sms
    • Reported on 12.0.2, tested on 12.0.4 and 5.1
    • AM Sustaining Sprint 44, AM Sustaining Sprint 45, AM Sustaining Sprint 46, AM Sustaining Sprint 47
    • 3
    • Yes
    • No
    • No
    • Yes and I used the same an in the description


      Bug description

      When creating an OAuth2 client endpoint using a rest call a number of cfgstore searches are triggered, one of which is an unfiltered search, in an environment with a large number of endpoints this can cause large etimes.

      How to reproduce the issue

      1. Using an OpenAM instance with an external DJ as config store
      2. Create an OAuth client using the rest endpoint e.g. for AM5 - 
        curl -X POST -H "iPlanetDirectoryPro: AQIC...3AAJTMQAA*" -H "Content-Type: application/json" -d '{
        "username": "OAuth2Test",
        "realm": "/",
        "AgentType": ["OAuth2Client"]
        }' http://openam.example.com:8080/openam/json/realms/root/agents/?_action=create

        or earlier versions - 

        curl \
         --request POST \
         --header "Content-Type: application/json" \
         --header "iplanetDirectoryPro: AQIC5wM...3MTYxOA..*" \
         --data \
           "com.forgerock.openam.oauth2provider.name":["My Test Client"],
           "com.forgerock.openam.oauth2provider.description":["OAuth 2.0 Client"]
          }' \
      1. Examine the DJ access log, and see a search similar to - 
        {"eventName":"DJ-LDAP","client":{"ip":"","port":34270},"server":{"ip":"","port":5389},"request":{"protocol":"LDAP","operation":"SEARCH","connId":8,"msgId":15070,"dn":"ou=default,ou=OrganizationConfig,ou=1.0,ou=AgentService,ou=services,dc=example,dc=com","scope":"one","filter":"(objectClass=*)","attrs":["o"]},"transactionId":"e1cd0ef0-17f1-48e9-b6a2-dd79ffe4d078-38264/0","response":{"status":"SUCCESSFUL","statusCode":"0","elapsedTime":531,"elapsedTimeUnits":"MILLISECONDS","additionalItems":" unindexed","nentries":5487},"timestamp":"2017-10-07T21:37:51.801Z","_id":"81ad2ef6-af66-4184-83c5-8b17064ab243-375655"}
      Expected behaviour

      A search for matching names without using unindexed attribute or broad filter

      Current behaviour

      I understand that it will need to search for matching names so you don't have duplicates but cannot see a reason for this search which when used with large deployments can cause slow creation (for example my screenshot above has 5487 clients and an eTime of 531, the use case given to us for a customer is to create over 100k clients)

      Work around


      Code analysis

      The code is kicked when AgentsRepo tries to create a profile and then SMS layer checks the existing config :

      Daemon Thread [http-bio-18080-exec-9] (Suspended (breakpoint at line 222 in SMSEmbeddedLdapObject)) 
          owns: SocketWrapper<E>  (id=13136)  
          SMSEmbeddedLdapObject.read(SSOToken, String) line: 222  
          SMSEntry.read(SSOToken) line: 699   
          SMSEntry.read() line: 676   
          SMSEntry.<init>(SSOToken, String) line: 469 
          CachedSMSEntry.getInstance(SSOToken, String) line: 355  
          CreateServiceConfig.createSubConfigEntry(SSOToken, String, ServiceSchemaImpl, String, String, Map, String) line: 311    
          ServiceConfig.addSubConfig(String, String, int, Map) line: 356  
          AgentsRepo.create(SSOToken, IdType, String, Map) line: 279  

      SMSEmbeddedLdapObject or SMSLdapObject send search request with objectclass=*

          public Map read(SSOToken token, String dn) throws SMSException,
                  SSOException {
              try {
                  SearchRequest request = Requests.newSearchRequest(DN.valueOf(dn), SearchScope.BASE_OBJECT,
                          smsAttributes.toArray(new String[smsAttributes.size()]));

      The above code is for embedded, but external configstore code does similar thing using LDAPRequests.newSingleEntrySearchRequest().

      We should either :
      1. change the filter so it will search for (||(objectclass=sunServiceComponent)(objectclass=sunService))
      2. search for RDN value


        Issue Links



              lawrence.yarham Lawrence Yarham
              robert.matthews Robert Matthews
              0 Vote for this issue
              5 Start watching this issue