Continuing my Christmas present to EMC.  I’ve talked about Application Separation and the need to Focus on the Core.  Now it is time to revisit a critical piece of the puzzle, Identity Management.

This is not a new topic for me. One of my most popular posts this year is the Single Sign-On, SAML, and Authentication in Documentum post that I wrote back in 2007.  I’ve talked to EMC engineers and product managers about this issue repeatedly over the years.  It was one of those things that James McGovern always pinged EMC on when he was a regular blogger.

This is the reason that I feel eRoom died. This is what will stop application developers from using just any ECM platform.

What is Pie Rambling About?

Some background on the topic.  Identity Management consists of two simple parts.  There is Authentication, proving who you are, and Authorization, what do you have rights to do now that we know who you are.

Documentum has several means of Authentication:

• User synched with LDAP: While this is a pain at times, this creates an user object in Documentum that is kept in synch with the user in the LDAP directory.  Authentication credentials are passed through to the LDAP server to authenticate the users.  Groups can also be synchronized, including membership in those groups.
• Network authentication: An user account is created and told to authenticate against a “domain”.  This could be a local server account or on an LDAP directory.
• Internal user with encrypted password: Useful for test accounts and users external to your network.

In all cases, an user object is created within Documentum.  This is done in order to facilitate authorization.

Access to all content is controlled by Access Control Lists (ACLs).  Users and groups are assigned rights.  Since this is purely an internal Documentum function, if the user or group doesn’t exist in Documentum, they can’t be granted rights.

Access to perform actions in a specific Documentum application or process is controlled by roles.  These are basically groups that cannot be imported from an external source.

And This Killed eRoom How?

If you’ve ever used eRoom “Enterprise”, and I mean really USED it, you know that there is no way to keep the permissions on objects in the Content Server in synch with corresponding link(s) in eRoom.  This made non-eRoom interactions with content an issue.

If the security changed in one system, it only changed in that one system, leaving the permissions in the other unchanged.  I would take some elaborate coding, which I never saw anyone implement successfully to resolve this issue. I never tried because I thought EMC should solve the problem and I could never get the cost justified.  There were too many variables and we could get where we wanted, usually, by controlling the behavior of the users.

Of course, this crippled the potential of having eRoom as a front-end for Documentum. My most frequent advice, just use standard eRoom, skip the Content Server unless you really need it.

The core problem is that both systems have their own users and their own permissions.  Users in one system may, or may not, be in the other system.

What you got was two systems that could never really together.

We now see the same thing with SharePoint and Documentum, or any ECM platform and SharePoint.  You can use web parts, which are basically simple clients to Documentum, or you can use the Content Services which can store all content in the SharePoint Document Libraries in Documentum.  Just don’t restrict the permissions any further.

Two systems, two sets of security.  They typically both hit the same Active Directory server, but that means nothing.

Different content application, same problem.

Get ready folks, this problem is only going to get worse….

All This Waiting Around

Did you notice that the LDAP accounts are synchronized?  That means that any changes made between the synchronization attempts are recognized by Documentum.  If I remove a user from a group that is used to determine access to a piece of content, they will actually still have access until the next synchronization runs.

Anyone see a problem?

Now imagine I have a Federation setup.  That means I need to wait for the Federation synch to occur AFTER the LDAP synch has completed before any changes are replicated to the member repositories.

Anyone notice the lawyers getting interested?

The only thing that is instant is the disabling of users.  This is because Documentum asks LDAP to authenticate the user when they log into the system.  Of course, the user in question has usually been physically removed from system access, so it isn’t as impressive.

Time to Solve This

EMC is improving. Slowly…

Kerberos support is incoming.  SAML has been used with DFS.  That is a step in the right direction, but that just addresses authentication.  Read my old post on the topic for more information on SAML and Documentum.

For authentication, there is a big gapping hole.  Something like XACML might be useful.  Similar to SAML addressing authentication, it is an open approach to representing authorization.  You know the most interesting part about it…

EMC is on the OASIS Technical Committee! They’ve met at the RSA conference!  You know RSA, “The Security Division of EMC!” [The exclamation mark is mine, not part of their tag line.]

Maybe RSA and the Documentum architects could meet for lunch one day.

This is important.  How are you, Documentum, going to serve as a platform to manage content for a large organization if  you can’t manage the security of that content?

And all of you other vendors, don’t feel smug.  I pose the same question to you because this is a broad issue.

Look at Lee Smith‘s post on Case Management. In the comments, people talk about different systems needing to interact with different content that might be needed by the case management system.  What if one system restricts access to a document, does it get accurately reflected everywhere?  What if a records policy does something to the document, do the other systems know?  How will those conflicts be managed?

This is no small problem.  It also cannot be ignored as more and more applications look to access a common repository.  Allowing open methods that can work in conjunction with CMIS is a good first step.  Maybe Kerberos/SAML with the Access Control Lists from CMIS can do this now, but that doesn’t fix the synchronization delays.

Of course, what happens when I want an external Identity Management system to store my policies and entitlements?  Thing get more complicated. [BTW, anyone know what ever happened to the RSA Entitlements Policy Manager product?]

I’d like to see a strategy to address all of these challenges.  Something concrete that talks about the technical approach, not just “We plan to fix it.”.  Maybe show a little leadership in the field.

Never going to get to the future otherwise.