LDAP and Weblogic; Using ApacheDS as authentication provider for Weblogic

A Lightweight Directory Access Protocol (LDAP) server is often used to centralize management of users/groups/credentials within enterprises. An LDAP server stores user information such as group memberships and often also authorization/authentication data. You can use this information to authenticate on Weblogic Server. In this blog post I will provide a small introduction, some suggestions on how LDAP connections can be debugged and an example how an LDAP server (ApacheDS in this example) can be used as an external authentication provider in Weblogic server.

Introduction

Weblogic server, authentication providers and LDAP servers

Weblogic server provides an abstraction layer for security services; Oracle Platform Security Services or OPSS. See http://docs.oracle.com/cd/E21764_01/core.1111/e10043/underjps.htm. This abstraction layer / framework makes it possible for applications running on Weblogic server to have one API to talk to. They do not need to know details on how to interface with each security provider separately.

Beneath this API can be several security providers as is shown in the image below. These providers can be implemented by for example LDAP servers. There are also other options available such as using an RDBMS. See for examples http://docs.oracle.com/cd/E29542_01/web.1111/e13707/atn.htm.

Some applications can only talk to one security provider. You have two main options to present the different providers as one (virtualizing providers). Oracle Virtual Directory (OVD); see http://www.oracle.com/technetwork/middleware/id-mgmt/index-093158.html. OVD allows different providers to be presented as a single LDAP server. It is quite flexible and configurable and even allows using a plain database table as source data for your authentication. It does require a separate license though. Another option is using LibOVD which is provided as part of Weblogic Server license. It allows virtualizing several LDAP security providers (but only LDAP providers!). It has less features then OVD and is more limited in possible configuration. It for example does not have its own webinterface. See for more information: http://fusionsecurity.blogspot.nl/2012/06/libovd-when-and-how.html

Debugging authentication

In you click on a server and go to the debug tab, you can set several debug scopes related to authentication/authorization. I would suggest the following (especially DebugSecurityAtn is important):

You can now see a lot of security related information in DefaultServer.log located in C:\Users\maart_000\AppData\Roaming\JDeveloper\system12.1.3.0.41.140521.1008\DefaultDomain\servers\DefaultServer\logs in my case since I'm using the JDeveloper Integrated Weblogic Server.

If I try to login with a non existing user (for example dummy) I get the following (among a lot of other things):

<BEA-000000> <LDAP Atn Login username: dummy> 
<BEA-000000> <authenticate user:dummy> 
<BEA-000000> <getConnection return conn:LDAPConnection { ldapVersion:2 bindDN:""}> 
<BEA-000000> <getDNForUser search("ou=people,ou=myrealm,dc=DefaultDomain", "(&(uid=dummy)(objectclass=person))", base DN & below)> 
<BEA-000000> <DN for user dummy: null> 
<BEA-000000> <returnConnection conn:LDAPConnection { ldapVersion:2 bindDN:""}> 
<BEA-000000> <getConnection return conn:LDAPConnection { ldapVersion:2 bindDN:""}> 
<BEA-000000> <DN for user dummy: _NOT_EXIST_> 
<BEA-000000> <returnConnection conn:LDAPConnection { ldapVersion:2 bindDN:""}> 
<BEA-000000> <javax.security.auth.login.FailedLoginException: [Security:090302]Authentication Failed: User dummy denied

This indicates an LDAP connection can be made (Weblogic is provided with it's own 'internal' LDAP server). It also shows the LDAP query used and that the DN (distinguished name) for dummy cannot be found.

When I login to the server with user Weblogic but a wrong password, I get the following:

<BEA-000000> <LDAP Atn Login username: weblogic> 
<BEA-000000> <authenticate user:weblogic> 
<BEA-000000> <getConnection return conn:LDAPConnection { ldapVersion:2 bindDN:""}> 
<BEA-000000> <getDNForUser search("ou=people,ou=myrealm,dc=DefaultDomain", "(&(uid=weblogic)(objectclass=person))", base DN & below)> 
<BEA-000000> <Retrieved guid:98DDA8501A4011E4AF6BC34CE98F6E2A> 
<BEA-000000> <DN for user weblogic: uid=weblogic,ou=people,ou=myrealm,dc=DefaultDomain> 
<BEA-000000> <returnConnection conn:LDAPConnection { ldapVersion:2 bindDN:""}> 
<BEA-000000> <authenticate user:weblogic with DN:uid=weblogic,ou=people,ou=myrealm,dc=DefaultDomain> 
<BEA-000000> <getConnection return conn:LDAPConnection { ldapVersion:2 bindDN:""}> 
<BEA-000000> <authentication failed 49> 
<BEA-000000> <returnConnection conn:LDAPConnection { ldapVersion:2 bindDN:""}> 
<BEA-000000> <javax.security.auth.login.FailedLoginException: [Security:090302]Authentication Failed: User weblogic denied

Here you can see the server was able to determine the DN for user Weblogic. What you also see is that no connection to an external server is made. This is an indication the internal LDAP server is used.

Now let's try an external LDAP server as authenticator.

Weblogic and using a custom LDAP

Setting up an LDAP server

I decided I did not want to use OpenLDAP as authentication provider in Weblogic server. Why not? There is already a lot of information online about it and I did not like manual editing of configuration files and a lot of commandline. See for example the quickstart guide on http://www.openldap.org/doc/admin24/quickstart.html. A nice example on how you can use OpenLDAP to achieve Weblogic authentication can be read here: http://biemond.blogspot.nl/2008/10/using-openldap-as-security-provider-in.html. As a challenge I decided to try it with ApacheDS and Apache Directory Studio. See: http://directory.apache.org/. Looked like nice products and I could use a GUI for the LDAP server configuration.

You can install Apache Directory Studio which has an ApacheDS server included. Getting it up and running will take less then 5 minutes. For the initial connection see http://directory.apache.org/apacheds/kerberos-ug/4.2-authenticate-studio.html. Port is 10389, Bind DN is uid=admin,ou=system and the default password is secret.

As we can see, admin is member of the group Administrators.

If we want to create our own users, you can add them in the group ou=users. When adding a user, make sure it has the inetOrgPerson class. You can also copy the admin user to the ou=users group for reference.

In the Administrators group you can then add more uniqueMembers by DN. Users need to be member of this group to allow them to log into Weblogic console.

If you want to debug ApacheDS; it uses the Log4J logging framework so just locate your log4j.properties and set some debug options. INFO does not provide you with the exact LDAP queries/statements so I recommend using the DEBUG setting.

Configuring Weblogic

See for general information http://docs.oracle.com/cd/E17904_01/web.1111/e13707/atn.htm#i1216261. Generic LDAP 2 or 3 compliant LDAP servers are supported. LDAP v3 servers are required (as per specification) to be LDAP v2 compatible. Please mind that any change to the authentication provider configuration requires a server restart so it's recommended to configure it correctly in one go.

First create the authentication provider:

Set the provider and the default authentication provider to SUFFICIENT so it will be enough if a user is present in one of the LDAP servers. If you forget to set the default provider to SUFFICIENT, it will never get to the newly configured provider but will reject the login if the user is not found in the embedded LDAP (you can see in the debug logs that ApacheDS is not queried).

Do not forget to set the correct credentials/port to login to the LDAP server. See the below screenshot. The default password is still secret.

Also set the DN for users (ou=system,ou=users) and groups (ou=system,ou=groups). Changing this and testing new queries is relatively easy. Queries can be tested with for example Apache Directory Studio. Mind though that every change in the Weblogic configuration concerning the authentication providers, requires a server restart.

Restart the server. Now you can login using your new users from the ApacheDS LDAP server. If it fails, you now know how to debug it. Also read the tips in the conclusion part of this post to help you fix common issues.

LibOVD

If you want to use the users from the other LDAP server in for example the BPM Worklist application, you should read the following part: "Enabling Identity Virtualization" from https://blogs.oracle.com/bpmbestpractice/entry/setting_up_active_directory_lightweight. You can also make this change by editing a configuration file. See how on http://fusionsecurity.blogspot.nl/2012/06/libovd-when-and-how.html.

Configuring and browsing the Weblogic internal LDAP server

This is more just for fun since I stumbled upon this. It might be useful. I checked the internal Weblogic LDAP server to see what it's structure was. In order to do this, read the following: http://docs.oracle.com/cd/E17904_01/web.1111/e13707/ldap.htm#i1102166. You can set the password and then connect to it using for example Apache Directory Studio. (first use the Weblogic console to set the password under the domain configuration for the embedded LDAP server. use port 7001 to connect to and user cn=Admin).

I considered recreating this structure in my own LDAP server. This however could not be completely done because certain Weblogic specific objectClasses where not present in my own server. I noticed though that the group configuration was done at user level and the group had an URL specified to query for it's members. This is different then the way I had configured it in ApacheDS.

Conclusion

Developers who do not work a lot with LDAP servers might get frustrated trying to get things to work. It is bothersome that every configuration change related to an authentication provider, requires a complete server restart. Also debugging LDAP can be difficult.

I learned several things getting this to work;
- pay special attention to the control flags (such as SUFFICIENT and REQUIRED) and order of the authentication providers!
- check the log files to see if a connection to your new LDAP server is actually made.
- the Weblogic log shows the LDAP queries executed. you can test these same queries in Apache Directory Studio. It is useful to first test your queries in for example Apache Directory Studio before making changes in the Weblogic server configuration since every change requires a server restart.
- if Weblogic says a user cannot be found, it is not there. probably it is looking in the wrong (most likely internal) LDAP server. if this is the case, you probably forgot to set the control flag of the default authenticator (internal LDAP) to SUFFICIENT.