Tuesday, May 13, 2008
Outstanding questions for Directory Services Gurus
I have many outstanding questions on LDAP directory services that I think folks such as Jackson Shaw, Mark Wilcox, Rohan Pinto, Curt Devlin, James Bayer, Terry Gardner, Matt Hardin and others may be able to provide insight into...
1. There is a lot of talk about leveraging a virtualization layer but no discussion on when it is a better strategy to simply copy data. Most directories I have ran across aren't that big and most will fit into memory.
2. Mark Wilcox provided an example of virtualizing Microsoft ADAM that was technically sound but didn't talk about the economic aspects. He didn't mention what OVD costs but I have to assume it is pricier than an ADAM instance. Does it make sense to spend say $30K to virtualize something that costs say $3K?
3. Enterprise Applications such as Documentum use a syncronization paradigm for group structures and at some level this approach is fugly. Directories such as Active Directory have the ability to create dynamic group structures based on specifying attributes. How should products consume dynamic group structures? Additionally, what will cause Documentum, Alfresco and other products that are still doing LDAP syncronization in a legacy fashion to modernize?
4. If directory enabled products are still doing syncronization instead of binding at runtime, this would lead me to believe that the community at large needs to define best practices in creating directory enabled enterprise applications. Who is in the best position to lead this effort?
5. Without exploring the whole legacy conversation, shouldn't it be considered a best practice for modern applications to not even be aware of LDAP as a protocol? If an application instead interacted with an STS, shouldn't it pick up the attributes at runtime vs having hard-coded binding to a directory interactions?
6. Taking this one step further, if you have XACML and you are writing a PEP, why would your application ever need to know about LDAP?
7. Oracle has a wonderful product known as OctetString which allows a LDAP directory service to work with JDBC but this is on the client. This begs the question of whether products such as Sun One Directory Server, OpenLDAP, Microsoft Active Directory and others should instead figure out how to allow a SQL client to connect to the directory and support it natively. What prevents vendors from going down this route?
| | View blog reactions1. There is a lot of talk about leveraging a virtualization layer but no discussion on when it is a better strategy to simply copy data. Most directories I have ran across aren't that big and most will fit into memory.
2. Mark Wilcox provided an example of virtualizing Microsoft ADAM that was technically sound but didn't talk about the economic aspects. He didn't mention what OVD costs but I have to assume it is pricier than an ADAM instance. Does it make sense to spend say $30K to virtualize something that costs say $3K?
3. Enterprise Applications such as Documentum use a syncronization paradigm for group structures and at some level this approach is fugly. Directories such as Active Directory have the ability to create dynamic group structures based on specifying attributes. How should products consume dynamic group structures? Additionally, what will cause Documentum, Alfresco and other products that are still doing LDAP syncronization in a legacy fashion to modernize?
4. If directory enabled products are still doing syncronization instead of binding at runtime, this would lead me to believe that the community at large needs to define best practices in creating directory enabled enterprise applications. Who is in the best position to lead this effort?
5. Without exploring the whole legacy conversation, shouldn't it be considered a best practice for modern applications to not even be aware of LDAP as a protocol? If an application instead interacted with an STS, shouldn't it pick up the attributes at runtime vs having hard-coded binding to a directory interactions?
6. Taking this one step further, if you have XACML and you are writing a PEP, why would your application ever need to know about LDAP?
7. Oracle has a wonderful product known as OctetString which allows a LDAP directory service to work with JDBC but this is on the client. This begs the question of whether products such as Sun One Directory Server, OpenLDAP, Microsoft Active Directory and others should instead figure out how to allow a SQL client to connect to the directory and support it natively. What prevents vendors from going down this route?
