Implementing a custom user registry to consolidate LDAP servers and active directories?

The simple beauty of the custom user registry

On the surface, implementing a custom user registry is simple. While it differs slightly from one application server to the next, to implement a custom user registry, you typically only have to write a Java class or two that provides an implementation for half a dozen or so methods that do things like validate a password, or indicate whether a user is a part of a given group. It’s easy peasy.

For example, to create a custom user registry for WebSphere, here is the IBM WebSphere UserRegistry interface that needs to be implemented, along with the 18 methods you need to code:

com.ibm.websphere.security.UserRegistry

1. initialize(java.util.Properties)
2. checkPassword(String,String)
3. mapCertificate(X509Certificate[])
4. getRealm
5. getUsers(String,int)
6. getUserDisplayName(String)
7. getUniqueUserId(String)
8. getUserSecurityName(String)
9. isValidUser(String)
10. getGroups(String,int)
11. getGroupDisplayName(String)
12. getUniqueGroupId(String)
13. getUniqueGroupIds(String)
14. getGroupSecurityName(String)
15. isValidGroup(String)
16. getGroupsForUser(String)
17. getUsersForGroup(String,int)
18. createCredential(String)

Now remember, the goal here is not to invent a system for storing users. When implementing a custom user registry, there is typically an underlying data store in which the application is connecting. So perhaps the purpose of the custom user registry is to combine access to a combined LDAP server and a database system that has user information. Or perhaps there are three different LDAP servers that need to have consolidated access. Each of those systems will already have mechanisms to update a password or check if a user is part of a given group. Code for a custom user registry simply taps into the APIs of those underlying systems. There’s no re-inventing the wheel with a custom user registry. Instead, you just leverage the wheels that the underlying user repository already provides.

So it all sounds simple enough, doesn’t it? Well, it’s not. And there are several reasons why.

Ongoing connectivity concerns

First of all, just connecting to various disparate systems can be a pain. There’s the up front headache of getting credentials, bypassing or at least authenticating through existing firewalls and security systems that are already in place. Just getting initial connectivity to disparate user registry systems can be a pain, let alone maintaining connectivity as SSL certificates expire, or changes are made in the network topology. Maintaining connectivity is both an up-front and a long term pain.

LDAP server optimization

And then there’s the job of optimization. Authenticating against a single user repository is time consuming enough, especially at peak login times. Now imagine there were three or four underlying systems against which user checks were daisy chained through if..then…else statements. It’d be a long enough lag to trigger a user revolt. So even after achieving the consolidation of different LDAP servers and databases, there is time that needs to be invested in figuring out how to optimize access. Sometimes having a look-aside NoSQL database where users ids are mapped to the system in which they are registered can speed things up, although a failed login would likely still require querying each subsystem. Performance optimization becomes an important part of building the user registry, as every user notices when logging into the system takes an extra second or two.

Data quality issues

And if there are separate subsystems, ensuring data quality becomes a top priority as well. For example, if the same username, such as cmckenzie, exists in two sub-systems, which one is the record of truth? Data integrity problems can cause bizarre and difficult behavior to troubleshoot. For example, cmckenzie might be able to log in during low usage times, but not during peak usage times, because during peak usage times, overflow requests get routed to a different sub-system. And even though the problems may stem from data quality issues in the LDAP server subsystems, it’s the developers maintaining the custom user registry code who will be expected to troubleshoot the problem and identify it.

LDAP failure and user registry redundancy

Failover and redundancy is another important piece of the puzzle. It’s good to keep in mind that if the custom user registry fails, nobody can log into anything from anywhere. That’s a massive amount of responsibility for anyone developing software to shoulder. Testing how the code behaves when a given user registry is down, or figuring out how to make the custom user registry resilient when weird corner-cases happen is pivotally important when access to everything is on the line.

Ownership of the custom user registry

From a management standpoint, a custom user registry is a stressful piece of technology to own. Any time the login process is slow, or problems occur after a user logs into the system, the first place fingers will point is to the custom user registry piece. When login, authentication, authorization or registration problems occur, the owner of the custom user registry piece typically first has to prove that it is not their piece that is the problem. And of course, there certainly are times when the custom user registry component is to blame. Perhaps a certificate has been updated on a server and nothing has been synchronized with the registry, or perhaps someone has updated a row or column in the home grown user registry database, or maybe an update was made to the active directory? The custom user registry piece depends on the stability of the underlying infrastructure to which it connects, and that is a difficult contract to guarantee at the best of times.

So yes, on the surface, an custom user registry seems like a fairly easy piece of software to implement, but it is fraught with danger and hardship at every turn, so it is never recommended. A better option is to invest time into consolidating all user registries into a single, high performance LDAP server or active directory, and allow the authentication piece of your Oracle or WebSphere applications server to connect into that. For small to medium size enterprises, that is always the preferred option. That way you can concentrate on using the software and hardware that hosts the user records to be optimized and tuned for redundancy and failover, rather than trying to handle such problems in code that has been written in house. It also allows you to point your finger at the LDAP server or active directory vendor, rather than pointing fingers at the in-house development team when things go wrong.

Inevitably, there will be times when a custom user registry is required, and it has to be written, despite all of the given reservations. If that’s the case, I wish you the best of luck, and I hope your problems are few. But if it can be avoided, the right choice is to avoid, at all costs, the need to implement a custom user registry of your own.