Saturday, January 29, 2005

Directory technolgies and Identity Management

I saw that Mark Wahl and Kim Cameron have been talking a while back, and I like to see that. With Mark's background in LDAP directory technologies, I know that he has been thinking about this space for a long time.

When working on digitalMe at Novell, I really wanted to see directory technologies extended to become a primary platform for Identity. When I say "extended" it was because there are a lot of issues that we found when attempting to store identity in a directory.

There are numerous reasons that a directory is a logical place to store identity:
  • fully extensible schema for objects and attributes
  • authentication for verifying the user
  • access control down to the attribute level
  • flexible multi-protocol access
An extensible schema gave us the ability to quickly create a core identity representation. A "user" object with a list of attributes. What was powerful here was when a user interacted with a new entity and was prompted for some previously "unknown" attribute. This would be some attribute that might be common, but had not been pre-defined in our list of user attributes. With a directory we were able to ask the user for the value of that attribute, extend the schema, and populate the value. In a later iteration, we also looked for a way to allow the user to "alias" the new attribute to simply point at an existing attribute. This is the case where some attribute is called different things by different communities.

With directory authentication, we are able to verify who is talking to the directory and then enforce access control on that connection.

Access control, down to the attribute level, was one of the most powerful features that a directory provides. With this, we were able to determine the "visibility" of any particular identity attribute to any requestor. With most directories there is even the concept of a "public" or "anonymous" user making requests, and so we were able to expose those attributes that are considered "public." This is also what allows me to expose more information to people that I want to. These access controls could also determine who was able to modify any attribute of any object. So, for example, I might have an object that represents you in my directory, and I might choose to allow you to update and maintain some of your own attributes. It is important to see that I might choose to ... because I also might choose not to allow you to update your object. After all ... it's my directory. However if I trust you, why not allow you to keep me up to date on your identity if you want to?

Lastly, it is multi-protocol access that offered the ability to integrate with a wide range of identity solutions. At Novell we had internal proprietary protocols, LDAP, and even some HTTP/HTML/XML methods of access. I worked on a protocol that I called XDAP just before we announced digitalMe. It is almost a LID/FOAF parallel. What I did was to have XML data returned - in DSML format - when a request was received in the IETF RFC 2255 format. Even after leaving Novell I had a lot of fun experimenting with this further and using CSS and XSL to then directly render identity information as "documents" in the browser that looked just like the "real" documents in the paper world.

Over all ... I believe that directories could be one of the possible stores for identity information. There are, however, some limitations in their implementations that don't allow for many of the common identity request patterns ... like versioning and timestamping of attributes. Directories are not very well designed to account for how our identities evolve and change over time. I believe this is necessary to have effective identity management.


Post a Comment

<< Home