Tag Archives: LDAP


The StormPath blog has an interesting article exploring HTTP PUT vs POST in REST based APIs for managing identity information. The article is interesting and worth reading, but misses the bigger picture. It points out that both HTTP PUT and POST can be used for sending updates in a REST API, but the HTTP spec mandates the HTTP PUT be idempotent. The idempotent requirement dictates that for an HTTP PUT, all values must be sent on the request, not just the ones being modified by the client.

Now I am sure idempotent PUT operations are important to people that design ways to update html documents. But I’m not in that business and neither are you. I am in the business of designing and enabling distributed identity systems, and in that business you never send a modification request that passes data you don’t need to modify. Simply put, you have to assume multiple concurrent updates to the backend data.

Put another way the article could simply have said “Never use HTTP PUT for data modification”. And herein lies the most important lesson of REST APIs: the REST mechanism is the means by which to build distributed systems, not an end to itself. The fact that you are using REST does not obviate the principals of basic distributed system design.

Oh, but it gets worse. Assuming your data model is attribute-value based, some of those attributes are going to be multi-valued attributes. Just as a client should only transmit the attributes that are modified, it should also only transmit the value modifications for multi-valued attributes.

That’s why LDAP Modify works as it does. One common mistake developers make using LDAP is not doing proper multi-valued attribute updates. Likewise your REST API will not only need to support partial record updates but partials attribute value updates.

Enter the Migrator

One common business case we get is to migrate from various directory servers to AD. This is usually an issue of per user license cost but lower maintenance is also a factor. Companies are realizing that since they are maintaining AD anyway, why pay for and maintain other multiple directory servers as well? For employee accounts it usually doesn’t make sense to have the same account in two places and need additional processes just to keep them in sync.

There are several ways you can migrate directories. You could use a one-time import/export, a Metadirectory, or a provisioning system, but these approaches have several key drawbacks. One issue is that in most cases you can’t migrate the user passwords. Another issue that the migration may require custom attributes to be added to AD (try getting your AD team to agree to that).

But the biggest issue is that these directories exist for a reason. There are client apps, sometimes tens or hundreds, which rely on the information in the old directories. Most home grown apps written for one directory won’t be able to switch over to AD without extensive rewriting. Even commercial apps that support AD may require significant and disruptive configuration changes.

Enter the Migrator (obscure Disney reference intended)

A virtual directory can be your Migrator. The solution is to standup a virtual directory that merges your AD with the old directory into a single view that emulates the old directory. Run both directories side by side while migrating the accounts. When a password change is made the virtual directory can update both AD and the old directory with the new value, so after running side-by-side long enough, most of the passwords will have been migrated. Eventually the old directory can be retired.

This approach has two main advantages:

  • no changes need to be made to the client applications
  • no schema changes need to be made to AD.

There is a good white paper that covers this in detail on the OptimalIdM web site (no registration required).

Familiar Ground

Johannes Ernst is predicting the demise of the RDBMS (and by extension Oracle) due to the growing popularity of NoSQL. While these kinds of technology trends are hard to predict, there is a lot of logic to what Johannes is saying. He could very well be proven prophetic.

But this is familiar ground. We have been here before.

I remember in the mid 90’s when Object Databases were going to kill the RDBMS. Of course what really happened was that Object-Relational-Mapping APIs became popular instead.

Later XML Databases were going to kill the RDBMS. Instead RDBMS vendors added native XML capabilities to their mainline products.

There are specific functional areas where RDBMSs have been displaced. For instance LDAP directories have mostly replaced RDBMSs for identity and authentication information.  But this has not dented overall RDBMS usage.

So can NoSQL slay the RDBMS after OO and XML failed? Perhaps, but I wouldn’t short Oracle just yet.

Virtual Directories, O through S

Felix Gaehtgens of Kuppinger Cole has this to say about today’s virtual directory vendors:

As someone actively covering directory services and virtual directories, several innovations have caught my attention. The players within the virtual directory space are (in alphabetical order) Optimal IDM, Oracle, SAP, Radiant Logic, Red Hat, and Symlabs. When it comes to product development and innovation within the last year, you can split those vendors right down the middle. – Optimal IDM, Radiant Logic and Symlabs have been actively developing their product and churning out new features in new versions. The others have not been adding any features, but instead spent time changing logos, product names, default file locations and otherwise integrating the virtual directory products into the respective Oracle/RedHat/SAP identity management ecosystems. In fact, in some of the latter cases I ask myself whether it is likely to expect any virtual directory product innovations anymore.

I couldn’t help but notice that the entire virtual directory space as described by Mr. Gaehtgens spans only five letters of the alphabet (o through s). It doesn’t mean anything, but it’s still odd.

Physical and logical security convergence

Guy Huntington has had a lot of interesting things to say recently over at his AuthenticationWorld blog. I am not sure I completely agree with this, however:

Get all my PAC products to meet LDAP, SPML and XACML protocols.
This enables the products to easily interconnect with any of the logical identity and access management products. Most are now LDAP (Lightweight Directory Access Protocol) enabling communication between the enterprise directory and the PAC.

I’m not sure how compelling it is to SPML enable a product that is already LDAP enabled. As much as I like SPML, if the PAC identities are already externalized to LDAP, I’m not sure I see the value in provisioning via SPML.

Still, Guy makes some great points about the value of integrated PAC, Identity, and Security Management systems.

Accounts and Identities

Nishant Kaushik makes a very good point in his latest post on the Virtual Directory vs AD debate:

Here is my point. Martin says “AD is the directory…”. I say that “AD is a directory…”, and that too because Windows forced it on those enterprises, not because of their Identity Management needs. Yes, almost all the Fortune 500 have AD, but are they using it as an Identity Store, or as a Windows Account Store (which is very different)?

To answer the rhetorical question, the vast majority of AD deployments are not intended as identity stores (at least from my experience). In most enterprises AD is used to manage and control user access to Windows workstations, the intranet, email, and enterprise web applications. AD is not usually intended as a central repository of identity, although it often becomes that with varying degrees of success.

And here is the real crux of the matter: most enterprises don’t really want an identity solution. What they want is a “spend less money, get everyone access to what they need when they need it, keep the bad guys out, keep us out of the headlines, and the CEO would  really, really, like not to go to jail” solution.

They have been, in many cases, sold on the idea that identity management is the solution that they want. And indeed it can be part of the solution.

But here is the brutal truth, and the reason that enterprise identity management is so messy. Almost all enterprise applications are account-based not identity based. Very few products support externalizing the identity concept in their products. They most you will usually see is supporting AD or another LDAP for authentication. Less often you might see simple group membership for authorization. A few commendable vendors such as SAP support SAML, but it’s a very small list. Support for external identity services or other identity standards such as SPML and XACML is nearly  non-existent.

Which ties in with the question Nishant closes with:

By the way, why is it that architectural purists don’t ask when Microsoft will make it possible for Windows environments to work against any directory and not just AD, but Oracle Applications must support directories other than OID? In the end, both Microsoft and Oracle are wrong to push proprietary stores into deployments, contributing to the mess we have.

Halfway converted

Clayton Donley makes a very compelling argument that there is significant value is using a virtual directory even if an application only needs to access a single directory. So call me converted on that point.

Also, I should not have said that it’s not that difficult to write vendor independent LDAP code. It can be very difficult depending on what features are used. As Clayton points out there can be very significant differences between vendors in what should be standard behavior. I suspect there is also significant differences between virtual-directories as well, but I haven’t played with them enough to say for sure.

I often fall into the trap of thinking like a COTS software developer (since that is what I am), and forget the legions of in-house enterprise software developers. For COTS developers, writing vendor neutral LDAP code shouldn’t be that hard and should be the goal. For custom application development writing to a virtual directory may make a lot more sense. Especially if your enterprise has already deployed a virtual-directory.

It would be nice if someone maintained a KB of vendor specific LDAP behavior. If anyone knows of one that exists, please let me know.

And yes, IGF is coming. But it’s not available yet even for Java, much less .NET and scripting language developers.