LDAP - The Amphibian Of Identity Protocols

I took most of December off and being a football junkie - spent my non-work hours watching football, not writing blog posts.

[edit - I realized I initially posted without tying the headline to anything I had written. That's what happens when you start your post before a vacation. Anyway I meant to say that LDAP is like an amphibian. As an identity protocol it helped cross the chasm of silo-based, non-standards protocols such as individual databases into standards-based service-oriented identity protocols]

First - I would like to thank James for his feedback on where Oracle is more open - that feedback is the type of information our outreach teams (e.g. the ones delivering the classes) are looking for.

But this post is in response to this one written before the holidays but I didn't get a chance to respond before I took a vacation.

So let me address the questions individually:

1. Regardless of whether you are using Microsoft ADAM, OpenLDAP, OpenDS or Oracle Virtual Directory, the challenge of adding/removing users remains. Maybe they shouldn't think of identity management as something separate but instead figure out how to incorporate support for the SPML protocol directly into the core.

James is making a common mistake of confusing management tools with servers. Directory services are just that - services. That being said he is correct - LDAP management tools have generally sucked for a long time. For too long they assumed they were primarily being used for storing non-user or group data. This is why we have focused a great deal attention at improving this experience in our forthcoming Oracle Directory Services 11g. Also LDAP is not about identity management. It's the standard protocol for accessing identity attributes. Identity management encompasses much more including workflow (e.g. before you add Mark to Group X, make sure Person Y approves this or only add Mark to Group Z if he has attribute V), notification and being able audit these processes. Thus you need to have a product geared towards meeting those needs such as Oracle Identity Manager. That being said - OVD and OIM work well together which is why they are a part of Oracle Identity & Access Management Suite. So for example - you can use OIM to manage the identity workflow and build you audit reports while OVD is used to expose that data (either from the sources or from OIM data-store).

2. There are lots of LDAP tools that will allow you to administer users, browse schemas, etc but none that will allow you to actually model in LDAP. Consider how many tools allow you to produce an ER diagram, so why can't a few do the same for LDAP? I would love to see Mark Wilcox of Oracle take the lead in getting an Eclipse plugin created. Likewise, if Pat Patterson could do the same for Netbeans, it would rock.

I don't think there is a need to model LDAP anymore - because applications basically dictate the organization and it's generally better to keep it simple. Have a root (e.g. dc=oracle,dc=com) and thenĀ  have a couple of branches (e.g. ou=people, cn=users). One benefit of identity virtualization is that you can use different views to slice and dice data as necessary if applications have different types of requirements. And long-term ArisID Beans will completely eliminate even the notion of trees and branches. Apps will define their objects (whether in Java or C# or Ruby or whatever) and the identity attribute service will simply map the request to the sources automatically.

3. Someone should figure out a way to incorporate the notion of referential integrity into the protocol such that LDAP stores can have the same functionality as relational databases.

Most LDAP servers have this functionality now.

4. Most J2EE application servers support the notion of JDBC connection pooling. What would it take for the LDAP folks to push for a standard way of doing LDAP connection pooling to be incorporated into J2EE containers instead of everyone writing their own?

Don't disagree with the sentiment. One easy to get a good connection pooling is to use the current release of ArisID with the OVD provider. That would make it relatively simple to take advantage of OVD's LDAP adapter's connection pools. And longer term we are planning on embedding this functionality to be used by app servers (initial target is of course Weblogic but we could move to support others)

5. Many within OWASP talk about the importance of protecting against SQL Injection, but the notion of LDAP Injection also exists. What if the LDAP servers could provide an interface that would allow you to at least validate input? Would it be great if you could attach a regular expression to each AttributeClass?

I'm sure in theory it's possible to LDAP injection however, unlike SQL there are several ways to mitigate this in a non-code fashion. The easiest is that most apps don't need write access to LDAP thus make sure the connection they connect with don't have write access. Second, virtual directories can act as LDAP firewalls and can be used to only allow valid queries (OVD provides this via configuration in the Routing tab). Third the goal of IGF standard is that apps define what queries they need and only those area allowed by that application.


Post a Comment:
Comments are closed for this entry.

This is the blog for Oracle Consulting Security North America team. Edited by Mark Wilcox - Chief Technology Officer for Oracle Consulting Security - North America.


« June 2016