I’ve been meaning to get back to this topic for quite some time. Before moving onto other Standards topics, I want to try and conclude this thread on SAML. James and I traded responses about authentication and SAML, and I applaud James for taking time to look into the capabilities of the DFC to respond to my previous post. James did get several details of the DFC incorrect, but not regarding any points important to this discussion.

Creating Authenticated Sessions in Documentum

James’ most important statement is this, Security, in order to be done correctly requires server APIs which run in the address space of Documentum itself. He is correct. All Documentum sessions are created at the server. Using the DFC, you can either send the server the necessary login credentials, or a pre-authorized login ticket in the place of a password. The Server receives this information and either authenticates the login credentials against the authentication source(LDAP) or checks the validity login ticket, including its set expiration.

The login ticket is very useful. To create a login ticket for a specific user, you either have to have an existing session for that user, or you need a “superuser” session that you can use to spawn sessions for other users.

Now obviously, you wouldn’t just have a superuser session running just anywhere, or allow its authentication to be stored randomly. Though I wouldn’t attempt implementing SAML until D6 to leverage the more advanced capabilities of DFS, I could create a Web Application, or customize the authentication in an existing Documentum Web Application to work with SAML.

The process would depend on how SAML was implemented in the architecture. The core piece is that the Web Application would received the digitally signed SAML authentication and then, after validating with Documentum the existence of the user, request a session from the server on behalf of the user. I would probably restrict the level of access that any session generated in this manner would have.

A more secure, and thus more involved, manner would be passing the processing of the SAML request to the server from the Web Application. This would require a modification to the current authentication process, quite similar to how SSO is implemented in Documentum.

SSO versus SAML

Bex has been railing against SAML and has made some very good points. The biggest is that SAML is not really needed within an Enterprise that uses one single authentication source, like Active Directory. If all your users come from the same LDAP source, you can use a SSO product to leverage the users initial authentication and not worry about SAML.

Documentum provides integration with the SiteMinder SSO product. Other SSO products can be integrated as well differing degrees of effort. How much effort varies based on the product and how much code can be re-used from other efforts. What might be nice would be for the Java Open SSO product, or some other Open Source SSO product to be integrated into the system so that customers have a choice among products. However, I expect they will offer integration with RSA Access Manager first. Why? Check the owner.

From checking the effort to implement SAML support, it would be nearly the same level-of-effort as integrating with most SSO solutions. Of course, SAML leverages existing authentication sources while SSO products are another product in the infrastructure. The SSO does use the existing authentication structure, but it is just more overhead.

When is SAML Needed

When external partners need to access multiple systems within your architecture, SAML becomes a necessity. Before that, it becomes a matter of convenience. If SAML is supported out of the box, it can make life easier. However, Bex is correct. When you work within the Enterprise, SSO is where you need to start. You can get support implementing the solution from experienced professionals, hopefully. With SAML, you are looking at some work for now.

Translation, I don’t expect vendors to support SAML until multiple, loud, customers make it a requirement. They’ll point to their integration with SSO products for this requirement.