Been a busy week on the ECM standards front. There has been a lot of discussions going around. I’ve been silent on the topic as I’ve been focusing on learning more about SAML and XACML so that I can respond to James’ question. Plus, the dialogs are going great and I haven’t needed to keep them going.

I am not ready to give James an answer on XACML, yet. I feel I am ready to start a dialog on SAML though.

What is SAML?

Many of you may not know what SAML is. A very good description, complete with some solid examples is provided by OASIS. To put it very simply, it allows for Single Sign-On between web applications that may, or may not, have access to a common authentication source. Now, there is a lot that goes into that statement. The two applications must agree to trust each other. If that is the case, then it is just a matter of having a pre-determined agreement on a common identifier. SAML 2.0 introduces the ability to dynamically match identities.

That is all well and good. In the ECM worlds that I typically deal with, everyone is authenticating against Active Directory or some other LDAP source. That’s right James, Documentum does not require the creation of its own identity store. It makes a convenience copy of desired LDAP attributes on a schedule, but each authentication is made directly to the LDAP source. Now this may not be the binding that you desire, but it does make things more efficient when defining content security within the system. According to Bex, Stellent (now Oracle) takes it further, but without sitting down for a conversation, it is hard to say if that is the case or if it is just a matter of terminology.

The problem is in the passing of the authentication from one web application to another. Whether it is from SharePoint, BEA, Siebel, or any other application, the user should not have to keep entering the same authentication information over and over.

An ECM Example

Let’s take the Content Services for SharePoint. The goal is fairly simple, store and manage the Content and Records in Documentum. How this interface arrives in SharePoint is a discussion for another day. What we are concerned about is Active Directory. I connect into SharePoint using my normal account. The first time I access something from Documentum, I am prompted for a password. This is my Active Directory password. This is then stored and recalled by SharePoint whenever it needs to establish a new Documentum session.

This is not secure or convenient. If the password changes, it will need to be re-entered. In most secure networks, users change their passwords on a regular basis whether they want to or not. The failed attempts also generates a failed login attempt by the system in order to realize that the password is invalid. This is far from what I would call an ideal solution. It, unfortunately, has been the go-to solution by many vendors for quite some time.

How would it work with SAML? Simple, connect to SharePoint. When you attempt to access a Documentum resource, SharePoint will basically tell Documentum that this is in fact User A. Documentum would confirm that it trusts that SharePoint installation and returns a session for User A within Documentum. This is a bit of an oversimplification, but you see the advantages. No passwords are stored anywhere outside of Active Directory. The user is only prompted for authentication information during the creation of the first session.

What Next?

Ok, now what? Well, I could take some time out of my life and implement it within Documentum using the existing Documentum Foundation Classes, or wait for D6 and the arrival of the Documentum Foundation Services. DFS could make the task easier. Regardless of my approach, I wouldn’t need to deal with dm_check_password because I can create a session for any user that I want from the DFC if I am running the SAML Service Provider as a super user.

However, I don’t have enough hours in the day as it is to spend with my family, so I am going to pass for now. I definitely want to see what changes in D6 may make that whole concept easier to implement. Besides, I would have to learn a LOT more about SAML before I could intelligently design and write an extension to Documentum that would implement SAML.

Not working for any vendor, I can’t do more than ask for features and make the best case that I can for them. When possible, I get my clients to join in the chorus. SAML support from all the ECM vendors would be great but I’m not going to hold my breath.

Would one of the other standards be better? Not sure, but I think SAML solves the problem and it is out there. I’ll defer to any Identity Management people out there on that discussion. I could just use something sooner rather than later. The problem described above has been a problem for me since 2000. Not good.

Oh and James, the DFC is the Java interface into Documentum. You can basically build any application or integration you desire on top of it. In fact, the web clients that Documentum provides are all built on top of that very DFC. It is a very powerful tool that any experienced Java developer can leverage, with a little guidance from someone that knows how Documentum works.