Jumping over LDAP hurdles

LDAP is nothing new, but until recently I had never had the need to create LDAP lookups from an application to a directory server. Most of today’s platforms are usually LDAP compliant and handle this themselves, thereby abstracting developers and administrators from the LDAP server internals. Under normal circumstances you just have to read the platform/framework configuration documentation, create a system account for the application to use to bind to the LDAP server, and the platform takes care of the rest itself… well more or less :-).

Context

In the past I have read a lot about LDAP, and for some reason I had got the idea in my head that working with LDAP was difficult. In practice it turned out to be pretty simple once you got past a few hurdles. The ASP.NET application I was maintaining needed to switch from LDAP services supplied by Lotus Domino to Microsoft Active Directory. The application was using Active Directory for user authentication, but for all the other services it was using the LDAP directory supplied by Lotus Domino. There were historic reasons why this was the case, but it didn’t make sense anymore. To make matters worse, the data in two directory services were not synchronized so users were complaining that their user data was displayed incorrectly in the application UI. Of course this was true since it was being read from a mix of directory servers.

From my brief experience from working with this technology there are three basic hurdles you need to jump over to get something working.

Binding

The first thing you need to do is bind to a LDAP directory which is LDAP jargon for authenticating to the LDAP server. It sounds simple enough… However, when creating a URL I usually write the protocol specifier using lowercase characters. Doing this was giving me a very cryptic error from the Microsoft .NET runtime since I was using a protocol specifier that looked similar to ldap://server/query… Luckily Google was my friend on this occasion and I soon found out why I was getting complaints from the .NET runtime environment. It seems the .NET System.DirectoryServices.DirectoryEntry class does not like the protocol specifier in lowercase characters when connecting with Active Directory, so ldap:// has to be converted to LDAP:// which I still find to be a bit strange. Is this a platform specific bug? I could not find any information in any LDAP documentation that specifies that this is necessary…

Directory structure

The next thing to do is get familiar with your specific directory structure. I used the free Softerra LDAP browser to help me here. It will let you query the directory and display the results. It will also let you traverse the tree using the GUI which is useful to get a feel for the LDAP tree. Your tree will probably be site specific and you will need to know where to look to create a meaningful and efficient LDAP query. For lookup efficiency you should avoid starting your query at the directory’s root node. I was working for a large enterprise with thousands of users and groups. Starting a query at the wrong place would kill performance. In my case I was using an auto-complete function on the UI to call upon a backend lookup service so it had to be fast.

LDAP query syntax

Building the LDAP query is where you probably will spend most of your time. The query syntax itself may seem difficult to read at first, but you get used to it fast. If you’ve ever worked with a scientific calculator then I guess you can think of it working much that same way, only backwards :-). So to find an object that has objectclass=person and a shortname attribute starting with “joe” you could write (&(objectclass=person)(shortname=joe*)). The “&” works as a logical AND and the objectclass is the LDAP object type to return (there are other types of standard LDAP objects). Also note the wildcard. To expand our search example to find people with a shortname starting with “joe” or “kent”, the query could be written as (&(objectclass=person)(|(shortname=joe*)(shortname=kent*))). Notice the “|” symbol for the logical OR. Also note the parenthesis in the query limiting the AND and OR functionality. It may be hard to read at first. This is where a LDAP query tool as mentioned above may come in handy when testing your query.

My meeting with a celebrity

Last week, a colleage and myself were fortunate to participate at a one day GSE Nordic WebSphere User Group conference held at Bouvet’s offices in Oslo. One of the conference speakers was Stefan Hepper from IBM Germany. Stefan works as the WebSphere Portal Programming Model Architect and leads the programming model part of IBM’s flagship portal product, IBM WebSphere Portal Server. However, more importantly (at least to me), he had the honorable task of working as specification lead for the JSR-168 Portlet version 1.0 specification, and is currently working as specification lead on the new JSR-286 Portlet version 2.0 specification. Naturally, Stefan spoke primarily of the new features in the upcoming WebSphere Portal Server version 6.1 product in the context of JSR-286, but the two aforementioned portlet specifications influence every serious Java based portal server like IBM’s WebSphere Portal Server, SAP Enterprise Portal, Oracle Portal Server, Liferay and JBoss Portal Server, just to name but a few.

Stefan Hepper and the site authorHowever, although Stefan answered a lot of question during his talks, oddly enough, for me the highlight was sharing a taxi and a 20 minute train ride from the conference back to Gardermoen airport (main Oslo airport) where we loosely discussed portlets and portals in depth, and Stefan willingly shared his knowledge with us indiscriminately. It goes without saying that this guy really knows his “stuff”, but it was also quite fascinating to hear how a Java Community Process expert group works in practice. I admit that I knew little of how the JCP works behind the scenes before our conversation, but I got the impression that Stefan is responsible for a whole lot of the final specification work and seems to carry a “heavy burden” by leading the group. However, you won’t find a nicer guy willing to help you with anything related to Java portlet/portal development should you need to call upon him for help.

As you may know, the JSR-168 specification is implemented and supported on almost every Java based portal server. The JSR-286 specification is expected to be finished in april 2008 and introduces quite a lot of new features. If memory serves me correctly, Stefan mentioned that the specifcation API has grown by over 100% since version 1.0. IBM WebSphere Portal Server 6.1 is scheduled for release sometime in the second quarter of 2008 and will support portlets complying with either of the portlet standards. It is also possible to communicate between portlets developed on either standard something that was not possible before between the proprietary IBM Portal API and the JSR-168 implementation.

I also mentioned to Stefan that I thought it was odd that there were so few JSR-168 or porlet related books available on the market. It just so happens that he has co-written and almost finalized a Manning book that was never published. It happens to be available for free download from the Manning web site, but requires registration (free). The book is titled “Portlets and Apache Portals” and it looks good. It also seems to cover WSRP (Web Services for Remote Portlets, version 1.0) and also portlet development using JSR-127 (Java Server Faces).