More Thoughts on ADAM

So James has responded back to me on ADAM.

"I would love to know your thinking on why a database itself can't be
exposed via the LDAP protocol? For example, what would prevent
Microsoft from allowing
SQL Server
to be accessed by not only the TDS protocol but also LDAP? The code
required to make this happen, wouldn't be too difficult for a talented
team to get right. Of course, if you have less talented individuals
then performance or other factors may emerge. Anyway, by putting it
into the DB itself, wouldn't it help customers avoid purchasing yet
another product with yet another support model?"

The point isn't to just use DB for LDAP. The purpose is that you have existing databases (which could be Oracle, SQL Server, DB2, MySQL, etc) that contain existing data you wish to integrate into an identity infrastructure. OVD allows you to quickly and easily do this. And while it's technically not hard to write the back-end code to that - it does take skill and effort to make it easy to configure and support. Additionally this doesn't count for other features we have such as renaming attributes on the fly, translating namespaces and of course linking data together (e.g. user your AD username and password, but link to data stored in HR for a complete real-time picture of your identity data).

"Relational databases have always had the notion of a view and it was built-in the database without requiring an extra product. So, isn't this another scenario where Microsoft or other LDAP vendors should be thinking about views for LDAP?"

OVD does views today.. I can't speak to whether other vendors should or shouldn't do that.

"OK, so what would be the real reason why the AD schema can't be
extended? Microsoft provides all the right tools. Is it stupid thinking
in large enterprises?"

I don't disagree with the fact that Microsoft allows you to extend schema. I think there are two primary reasons why organizations don't want to extend AD schema. First is that there is not currently anyway to remove added elements. Second is the more data you add into AD, the more impact it has on AD replication. This in turn can effect desktop login performance. And thus organizations try to keep AD lean. I'm not saying you can't or shouldn't extend AD schema - I'm just pointing out that in many organizations - this is not allowed.

OK, I guess I am now officially confused. I wasn't aware that the
concept of changelog was in any LDAP standard. If ADAM doesn't
implement changelog, does this make ADAM non-LDAP compliant? I do know
that the use of changelog isn't just limited to provisioning tools and
fugly ECM products also leverage (used in the negative sense) this functionality.

It's not standard in terms of any RFC - but it is standard in the fact that every other storage-based LDAP server provides one. I wouldn't say ADAM is not LDAP compliant. Lack of changelog does make it harder to integrate with systems who wish to replicate ADAM data. While you can use other attributes (for example modifytimestamp) the problem is that without changelog, you must reconcile the data to figure out what has changed. A changelog gives you specifically what has changed.

I guess I would ask Mark, to instead of questioning the usage of ADAM, help others outside of Oracle write better enterprise applications that bind natively to LDAP and don't require anything fugly like syncronization...

As I have expressed before - we are already doing this. OVD is one option to help with this because developers can just learn to interact with a single consistent interface instead of having to deal with different back-ends. It will be fundamental component of Oracle's "identity dial-tone" (aka Identity As A Service) concept.

We are also helping to drive a new API via Project Liberty - the Identity Attribute Service API - which is one of the Identity Governance Framework components which we hope will make it easy to use identity information on demand as developers interact with databases similar to frameworks like JDO or ADO.



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.


« February 2016