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

REST OAuth2 creation triggers objectClass=* search

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 12.0.2, 14.1.0
    • Fix Version/s: 12.0.5, 13.5.2, 6.0.0, 14.1.2, 5.5.2
    • Component/s: oauth2, sms
    • Labels:
    • Environment:
      Reported on 12.0.2, tested on 12.0.4 and 5.1
    • Sprint:
      AM Sustaining Sprint 44, AM Sustaining Sprint 45, AM Sustaining Sprint 46, AM Sustaining Sprint 47
    • Story Points:
      3
    • 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

      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 \
         '{"client_id":["testClient"],
           "realm":["/"],
           "userpassword":["secret12"],
           "com.forgerock.openam.oauth2provider.clientType":["Confidential"],
           "com.forgerock.openam.oauth2provider.redirectionURIs":
             ["www.client.com","www.example.com"],
           "com.forgerock.openam.oauth2provider.scopes":["cn","sn"],
           "com.forgerock.openam.oauth2provider.defaultScopes":["cn"],
           "com.forgerock.openam.oauth2provider.name":["My Test Client"],
           "com.forgerock.openam.oauth2provider.description":["OAuth 2.0 Client"]
          }' \
         https://openam.example.com:8443/openam/frrest/oauth2/client/?_action=create
        
      1. Examine the DJ access log, and see a search similar to - 
        {"eventName":"DJ-LDAP","client":{"ip":"127.0.0.1","port":34270},"server":{"ip":"127.0.0.1","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

      N/A

      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=*

      com.sun.identity.sm.ldap.SMSEmbeddedLdapObject.java
          public Map read(SSOToken token, String dn) throws SMSException,
                  SSOException {
                  :
              try {
                  SearchRequest request = Requests.newSearchRequest(DN.valueOf(dn), SearchScope.BASE_OBJECT,
                          SearchFilter.createFilterFromString("(objectclass=*)"),
                          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

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                lawrence.yarham Lawrence Yarham
                Reporter:
                robert.matthews Robert Matthews
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: