Single Sign-On, SAML, and Authentication in Documentum


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.

14 thoughts on “Single Sign-On, SAML, and Authentication in Documentum

  1. James has already replied. For more information on Documentum’s security, check this page on their website. Most people don’t implement all of the features of encryption between the client (Web Application Server) and the Content Server. It is there and only requires a digital certificate.

    Oh, and I think a better description of what Documentum stores from LDAP is cached information. If the LDAP server(s) that Documentum is aware of is down, those users do not get into the system.

    Like this

  2. Sujeet says:

    Hi,

    I am just wandering, can we access the contents from the documentum repository without prompting the user to enter the login information. i would like to run the scripts background. Help really appreciated.

    Regards,
    Sujeet

    Like this

  3. Short answer: Yes.

    Long answer: It depends on what you are trying to do. If you are just running scripts, you can use the DFC and connect through the code.

    So my question is, what exactly are you trying to accomplish? A simple use-case should help to clarify things.

    Like this

  4. Sujeet says:

    thanks for the quick reply. The idea is to populate the Advaced Search Page without propmting the login screen. I am hardcoding the userid, password, docbase name and domain.

    Sujeet

    Like this

  5. If your purpose is to provide search without authentication, then aside from losing the auditing and authorization for each user, you need to be sure to be cognizant of the licensing issues.

    Like this

  6. Sujeet says:

    thanks for the info about licesing, i wil let my PM knows about the risk involved. back to my problem, do you have any hints for accomplishing this..

    sujeet

    Like this

  7. I would suggest two things. One would be to read my more recent post on Authentication Design Patterns and the discussion on the EMC Developer Network. The Network itself is a useful resource.

    From a purely technical perspective, if SSO is not an option, I would continue your course, but maybe encrypt and move the authentication information into a properties file for use in your code. If you are feeling adventurous, try the Generated Credential Authentication approach that I mention.

    Like this

  8. Brinda says:

    Hi,

    I am lookin towards integrating Documentum and BPM to an external application. Both the EMC app server and the external application share the same authentication store and SSO provider.

    Can you please let me know if there is there an API exposed through DFS to perform the SSO (token based authentication) from an external product to documentum?

    Is there a way to access the SSO generated token from within the form adaptors and the BPM events to perform an SSO login to the external system

    Like this

  9. Bab says:

    Hi,

    great blog ! I love word press.

    Maybe this isn’t the best place for my question…. but…
    I’m working with Center Stage and I’d like to integrate my SSO system.

    I’m looking for information, guide for developers. Nothing.

    Do you have any idea?

    Thank you.

    Like this

  10. Hi Bab,

    actually I didn’t find much info on developing on CenterStage but if you look on our web site (www.solfit.ch) you will see that we already implemented SSO for CenterStage based on kerberos.
    You need to understand java, dwr, and ExtJS (ajax).

    I thought you might be interested…
    Raoul

    Like this

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s