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

Enabled "'Return User DN to DataStore" of LDAP auth-module is resulting in one redundant search for "uid=uid=demo" in the configuration store

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 13.5.1, 14.5.1
    • Fix Version/s: 13.5.3, 6.0.0, 5.5.2
    • Component/s: audit logging
    • Labels:
    • Environment:
      OpenAM 13.5.1
    • Target Version/s:
    • Sprint:
      AM Sustaining Sprint 48, AM Sustaining Sprint 49, AM Sustaining Sprint 50
    • Story Points:
      3
    • Needs backport:
      No
    • Support Ticket IDs:
    • Needs QA verification:
      Yes
    • Functional tests:
      No
    • Are the reproduction steps defined?:
      Yes and I used the same an in the description

      Description

      Bug description

      Enabled "'Return User DN to DataStore" of LDAP auth-module is resulting in one redundant search for "uid=uid=demo" in the configuration store. 

      In the older OpenAM eg 11.0.1, there is a redundant search for amadmin user but it not seen for non-administrative users 

      [30/Jan/2018:13:37:31 +0800] SEARCH REQ conn=7 op=10 msgID=11 base="ou=people,dc=openam,dc=forgerock,dc=org" scope=wholeSubtree filter="(&(uid=uid=amAdmin,ou=People,dc=openam,dc=forgerock,dc=org)(objectclass=inetorgperson))" attrs="dn"

      How to reproduce the issue

      #1. Using 13.5.1 embedded

      #2. Create a LDAP module with "'Return User DN to Datastore"  enabled

      #3. Login using that LDAP module using demo test id

       

      #!/bin/sh
      #set -vx
      
      openam="http://openam.internal.example.com:8080"
      user="demo"
      password="changeit"
      set -x ;
      curl -s --request POST --header "X-OpenAM-Username: $user" --header "X-OpenAM-Password: $password" --header "Content-Type: application/json" --data "{}" "$openam/openam/json/authenticate?authIndexType=module&authIndexValue=LDAP1" | jq -r .tokenId
      ~
      

      To see the issue quickly, disable the cache com.iplanet.am.sdk.caching.enabled in the default server setting.

       

       #4. Observe the access log in OpenDJ

       

      [08/Feb/2018:09:23:58 +0800] SEARCH REQ conn=15 op=71 msgID=72 base="ou=people,dc=openam,dc=forgerock,dc=org" scope=sub filter="(&(uid=uid=demo,ou=people,dc=openam,dc=forgerock,dc=org)(objectclass=inetorgperson))" attrs="sunIdentityServerPPInformalName,sunIdentityServerPPFacadeGreetSound,uid,manager,sunIdentityServerPPCommonNameMN,sunIdentityServerPPLegalIdentityGender,preferredLocale,iplanet-am-session-get-valid-sessions,sunIdentityServerPPFacadegreetmesound,iplanet-am-user-password-reset-question-answer,telephoneNumber,employeeNumber,iplanet-am-user-admin-start-dn,iplanet-am-user-success-url,sunIdentityServerPPDemographicsDisplayLanguage,iplanet-am-user-federation-info,objectClass,sunIdentityServerPPDemographicsLanguage,authorityRevocationList,sunIdentityServerPPLegalIdentityDOB,sunIdentityServerPPSignKey,sunIdentityServerPPEmploymentIdentityOrg,createTimestamp,sn,iplanet-am-session-max-caching-time,iplanet-am-session-quota-limit,sunIdentityServerPPEncryPTKey,iplanet-am-session-max-session-time,sunIdentityServerPPCommonNamePT,sun-fm-saml2-nameid-info,sunIdentityServerDiscoEntries,iplanet-am-user-login-status,sunIdentityServerPPCommonNameCN,distinguishedName,iplanet-am-session-max-idle-time,cn,sunIdentityServerPPLegalIdentityVATIdType,iplanet-am-user-password-reset-options,iplanet-am-user-federation-info-key,preferredlanguage,sunIdentityServerPPDemographicsAge,inetUserHttpURL,oathDeviceProfiles,iplanet-am-user-alias-list,sunIdentityServerPPEmploymentIdentityJobTitle,sunIdentityServerPPFacadeNamePronounced,sunIdentityMSISDNNumber,sunIdentityServerPPMsgContact,givenName,oath2faEnabled,sunIdentityServerPPLegalIdentityMaritalStatus,devicePrintProfiles,memberOf,sun-fm-saml2-nameid-infokey,iplanet-am-session-service-status,sunIdentityServerPPLegalIdentityVATIdValue,userPassword,sunIdentityServerPPFacadeMugShot,sunIdentityServerPPEmploymentIdentityAltO,iplanet-am-user-auth-config,assignedDashboard,iplanet-am-user-failure-url,sunAMAuthInvalidAttemptsData,kbaInfo,sunIdentityServerPPLegalIdentityLegalName,adminRole,sunIdentityServerPPCommonNameAltCN,kbaActiveIndex,dn,iplanet-am-session-add-session-listener-on-all-sessions,userCertificate,mail,sunIdentityServerPPLegalIdentityAltIdValue,iplanet-am-user-password-reset-force-reset,caCertificate,sunIdentityServerPPEmergencyContact,sunIdentityServerPPDemographicsBirthDay,sunIdentityServerPPFacadeWebSite,preferredtimezone,pushDeviceProfiles,sunIdentityServerPPLegalIdentityAltIdType,sunIdentityServerPPCommonNameSN,sunIdentityServerPPAddressCard,postalAddress,iplanet-am-session-destroy-sessions,modifyTimestamp,inetUserStatus,iplanet-am-auth-configuration,iplanet-am-user-auth-modules,iplanet-am-user-account-life,sunIdentityServerPPCommonNameFN,sunIdentityServerPPDemographicsTimeZone"
      
      [08/Feb/2018:09:23:58 +0800] SEARCH RES conn=15 op=71 msgID=72 result=0 nentries=0 etime=2   <=====
      
      Expected behaviour
      It should not do this redundant search
      
      Current behaviour
      It is performing this redundant search 
      

      Work around

      Disabled "Return User DN to DataStore"

      Cause

      This seems to be done by the audit logging in AbstractAuthenticationEventAuditor.java in

          protected void populateAuditRequestContextUserIdFromUniversalId(String principalName, String realm) {
                  AMIdentity identity = IdUtils.getIdentity(principalName, realm);
                  if (identity != null) {
                      getAuditRequestContext().putProperty(USER_ID, identity.getUniversalId());
                  }
         }
      

      It seems this may be a fallback setup to set the USER_ID as specialization or later may
      set this based on the token.getUserId() instead of running the LDAP. Presumably
      if the principalName is already a DN maybe we just logged the principalName.
      At the moment, it seems this query LDAP (if the user cache is disabled) everytime.

        Attachments

          Activity

            People

            • Assignee:
              chee-weng.chea C-Weng C
              Reporter:
              sam.phua Sam Phua
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: