Virtual Identity Dialogue

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.

Over at Ash's Identity Management Rantings - Ash had a post asking questions about a topic that never seems to go away - "virtual directories and persistent cache".

This seems to be Ash's response to an earlier post by Clayton.

Ash had two questions:

1. Since performance is the main point here, does any one have numbers on the performance hit caused by virtual directories?

The overhead is absolutely minimal - it's generally around 2-5 milliseconds. And worst I've ever seen is around 50 milliseconds (remember that's still only 5/100s of a second). This includes doing a join of data. In short the performance is effectively the same as applications directly accessing the original source. Or to put it another way - there is a telco in Europe who uses OVD to authenticate all of their 3G phone users. Without using any cache within OVD. If direct access is sufficient for a telco - it is going to be more than adequate for any traditional IT application.

2. Is performance the only real justification for persistent cache?

When customers mention "persistent cache" - typically they are concerned on performance.  Usually this is because they have a mis-conception on direct access overhead. The other reason I've heard for customers becoming interested in persistent cache is if the source becomes unavailable. However, a persistent cache is probably not the best way to address this issue. There are two reasons for this. The first reason is that most of the time your primary resources are mission critical to the point if they are not functioning, the company is not functioning regardless if it was copied or not (e.g. if AD goes down, you can't login to Windows). The second reason is that spending the effort to make those systems redundant/highly-available will generally pay bigger dividends then synchronizing that data to another database that wouldn't help make the core application that generates the data more redundant.

Also "Blink Industries" added this in the comment to Ash's post:

"I thought the whole point of the cache is to lighten the load against the system as a whole. It's a compromise of data freshness for performance. Plus the entire point of a cache is to "cache" frequently used data, of course depending on the algorithm used (LRU, MRU, etc.). I also assume that the cache is adjustable and can have specific timeouts for freshness. I think for a highly trafficked directory this is a great trade-off."

I posted this here because it allows me to address a key difference in caching. OVD does provide a Cache plug-in that is granular - you can apply it globally or per adapter. It also doesn't require any other data-store (or software license, neither of which our competition can currently claim).  But the reality is that it usually never needed (I don't know of any production use of it including in high volume/low latency like phone activation or online-user registration). This is because caching already occurs at other points in the system. Pretty much every enterprise data source has a built-in cache. Additionally the clients that talk to OVD - are usually caching the results. And finally given modern hardware and software - I doubt any enterprise has reached any capacity level on their enterprise identity stores. Thus no actual need for any type of cache at the virtual directory layer.