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

Data store with identities that do not match user search attr cause server error



    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 6.0.0, 6.5.0
    • 6.5.0,, 6.0.1
    • console
    • AM Sustaining Sprint 50, AM Sustaining Sprint 51
    • 1


      Bug description

      Setting up a datastore that includes identities which do not match the user search attr cause Internal Server error when viewing Identities tab.

      How to reproduce the issue

      1. Deploy latest master AM 6.0.0 snapshot in tomcat 7.  For my testing, installed in linux CentOS env, selinux set to permissive (not enforcing) and have installed separate OpenDJ 3.5.2 with a backend dc=example,dc=com setup that includes a number of identities.  Most have a dn of uid=testuser[n]....  However from other testing, some have a dn of mail=testuser[n].
      2. Perform initial config of AM.  User repo set to use config repo (embedded).
      3. Login to admin console.  Create new realm, e.g. subscribers.
      4. In new realm, delete embedded datastore.  Create a new datastore that points to separate OpenDJ env above.  Save.  Note that I had to fill out server details tab first, then save, then go to Persistent search and set persistent search dn.  Otherwise I ran into a variation of bug --OPENAM-12538-- (values I have not yet saved are reverted).
      5. Navigate to Identities menu option.


      Note: ldapsearch of separate user repo attached - see dn that has mail=... instead of uid=.

      Expected behaviour
      Identities from datastore matching user search attr should be listed
      From other tests, this has worked this way in previous 6.0.0 snapshots and previous versions of AM.
      Current behaviour
      demo user (from embedded datastore that has been removed) is shown (only occurs the first time attempted) and a red error message box appears 'Internal Server error' (occurs on each navigate to Identities option).
      In debug logs, I see the following:
      ERROR: IdentityResourceV3.queryCollection caught exception
              at org.forgerock.util.Reject.checkNotNull(Reject.java:82)
              at org.forgerock.util.Reject.checkNotNull(Reject.java:63)
              at org.forgerock.opendj.ldap.Ava.<init>(Ava.java:483)
              at org.forgerock.opendj.ldap.Rdn.<init>(Rdn.java:255)
              at com.sun.identity.idm.AMIdentity.<init>(AMIdentity.java:270)
              at com.sun.identity.idm.AMIdentity.<init>(AMIdentity.java:225)
              at com.sun.identity.idm.AMIdentity.<init>(AMIdentity.java:205)
              at com.sun.identity.idm.server.IdServicesImpl.combineSearchResults(IdServicesImpl.java:2507)
              at com.sun.identity.idm.server.IdServicesImpl.search(IdServicesImpl.java:1487)
              at com.sun.identity.idm.server.IdCachedServicesImpl.search(IdCachedServicesImpl.java:616)
              at com.sun.identity.idm.AMIdentityRepository.searchIdentities(AMIdentityRepository.java:380)
              at com.sun.identity.idsvcs.opensso.IdentityServicesImpl.fetchAMIdentities(IdentityServicesImpl.java:1021)
              at com.sun.identity.idsvcs.opensso.IdentityServicesImpl.searchIdentityDetails(IdentityServicesImpl.java:519)

      Work around

      Have not tested this - but assume that if identities in datastore that do not have a matching dn to search attr are removed, then this will work as expected.


      AMIdentity id = new AMIdentity(token, mname, type, orgName,
              (String) amsdkDNs.get(mname));
      results.addResult(id, combinedMap);
      mname is null in the above case where the identity from the datastore has a dn that does not match the search attribute.  E.g. in this case the dn was mail=testmail@test.com,... and there was no uid attr.  See screenshot of debug information.  Should these lines only be executed if the mname is not empty?




            lawrence.yarham Lawrence Yarham
            lawrence.yarham Lawrence Yarham
            Filip Kubáň [X] Filip Kubáň [X] (Inactive)
            0 Vote for this issue
            6 Start watching this issue