Monday, December 29, 2014

Weblogic LDAPAuthenticator configuration; the GUID Attribute

LDAP servers can be configured to use as authenticator in Weblogic Server. In order to efficiently use an LDAP server, it must be possible to uniquely identify LDAP objects. GUID attributes can be considered a unique identifier for an LDAP object. There are several specific and some more generic LDAP authentication providers available for Weblogic Server. The specific authentication providers have default GUID (global universal identifier) attributes (see here at 'Use of GUID and LDAP DN Data in WebLogic Principals'). When using the generic Weblogic Server LDAPAuthenticator, there is no default GUID attribute. In order for LDAP caching to work and to allow browsing of group memberships for users, the GUID attribute needs to be defined. The entryUUID is a good candidate for this since every LDAP server should support it. See RFC 4530. Also see here.

In my example, I've used the user 'maarten' to authenticate myself with when logging into Weblogic Server. The user 'maarten' is member of the groups Administrators and DummyGroup. The debug information was acquired by setting the DebugSecurityAtn flag as described here. Weblogic Server was used and ApacheDS 2.0.0 as LDAP server. For the configuration of ApacheDS/Weblogic Server, I've used the following:

GUID Attribute set to entryUUID

In the below example, the GUID attribute is set to 'entryUUID'. As you can see, the GUID is correctly determined and there where no errors during authentication.

 <LDAP Atn Login username: maarten>   
 <authenticate user:maarten>   
 <getConnection return conn:LDAPConnection {ldaps://localhost:10389 ldapVersion:3 bindDN:"uid=admin,ou=system"}>   
 <getDNForUser search("ou=users,ou=system", "(&(uid=maarten)(objectclass=person))", base DN & below)>   
 <Retrieved guid:ca05de8f-89d8-47d7-b83a-d0bc5e63f7f8>   
 <DN for user maarten: uid=maarten,ou=users,ou=system>   
 <returnConnection conn:LDAPConnection {ldaps://localhost:10389 ldapVersion:3 bindDN:"uid=admin,ou=system"}>   
 <authenticate user:maarten with DN:uid=maarten,ou=users,ou=system>   
 <getConnection return conn:LDAPConnection {ldaps://localhost:10389 ldapVersion:3 bindDN:"uid=maarten,ou=users,ou=system"}>   
 <authentication succeeded>   
 <returnConnection conn:LDAPConnection {ldaps://localhost:10389 ldapVersion:3 bindDN:"uid=maarten,ou=users,ou=system"}>   
 <LDAP Atn Authenticated User maarten>   

I can browse the groups my user is in also without errors:

GUID Attribute empty

The following doesn't work well when the GUID Attribute in the LDAPAuthentication provider of Weblogic Server is left empty.

Logging in

After the first login, the below error occurs. The second login allows you to access the Weblogic console:

<authenticate user:maarten>   
<getConnection return conn:LDAPConnection {ldaps://localhost:10389 ldapVersion:3 bindDN:"uid=admin,ou=system"}>  
<getDNForUser search("ou=users,ou=system", "(&(uid=maarten)(objectclass=person))", base DN & below)>   
<returnConnection conn:LDAPConnection {ldaps://localhost:10389 ldapVersion:3 bindDN:"uid=admin,ou=system"}>   
<java.lang.NullPointerException at  

When disabling the cache, this behavior and corresponding error does not occur. You can guess where the NullPointerException is coming from.

Browsing user groups

When requesting user group memberships in the Weblogic Console (the Groups tab after clicking on a user under the security realm), it fails with a NullPointerException.

 An unexpected exception has occurred processing your request   
 Message: Stack java.lang.NullPointerException at at at Trace: at at   

GUID Attribute defined incorrectly

When I define the GUID attribute incorrectly, I do not get any errors during authentication and when browsing which groups my user is in. I can imagine though (based on errors when the cache is enabled and the GUID Attribute is not specified) that the GUID plays a role in the LDAP cache functionality in Weblogic Server. Should this be the case, some unwanted behavior could possibly occur like inefficient caching or worse, wrong LDAP cache returns and resulting security issues.