Time for some more dialog with James McGovern. I love this kind of discussion because it raises awareness of the issues in the community. James replied to my last post on Standardizing Authentication. There is a problem with written communication sometimes. No matter how clearly you think you write or explain something, someone will always either misread, misunderstand, or misinterpret something. Before I get into that, two things first.

In another post, James says something nice about ECM. Understand that ECM provides value regardless of whether it has standards. Can you feel the love? He does qualify that he isn’t pleased with the vendors, but we now know how he really feels.

Second, I wanted to say that James is dead on with this statement regarding SAML and Documentum. The beautiful thing is that you shouldn’t have to learn how to write this type of thing as this should be out of the box. He is absolutely correct. I shouldn’t even need to think about how I would implement SAML in Documentum. That is EMC’s job. Now on to the rest of James’ response/analysis.

A Friendly Discussion

Overall James begins with pointing out some details about SAML that I had read about and wasn’t focused upon very much. I’m not gearing to be an expert on it at this time. While I think that SAML would help me faster than many other approaches, and should be fairly simple to implement, the odds of my getting to work with it outside of my spare time is slim. Not to say that the details that James discusses aren’t important, but a man in the desert will gladly settle for some water. After that they will dream of better things like a gin and tonic.

I really hope that enterprises aren’t duplicating all their users just because ECM products require convenience copies.

Just going to reiterate what I said when I referred to Stellent’s approach, as outlined by Bex Huff. We need to make sure we have a common lexicon here. If Bex and I met for a five minute chat, I bet either of us would be able to clearly describe the differences and similarities of Stellent and Documentum when it comes to users. If I try and clear this up through the written word, I suspect that we would be talking about this for the next six months.

I really hope you are kidding. I wonder what Gunnar Peterson and all of the folks who oversee security would think about an approach that would require a normal user to run as a superuser? My opinion is that is simply fugly. Sounds like an opportunity to gain escalated priveleges to me.

I am not kidding, nor am I saying what you apparently thought I said. My receiving service my be connected to Documentum as superuser. When it receives the SAML message, it validates everything and then create a new session for the incoming user based on the rights that the now authenticated user has within Documentum. Trust me when I say that I make a habit of only giving out those rights that I have to give out. Never any more.

We all know that ECM is more of the follow-me culture and there is no true leadership in this space. Your clients don’t have to wait for every vendor to implement. If you get your clients to join in the chorus to get one and only one vendor to implement, the rest will follow.

James makes a better point here than he may have meant to make. A majority of my clients are Documentum clients. So if I got ALL my clients to chime in, they would most likely only be heard by Documentum. However, if James is right and the rest of the vendors follow, that could be good enough.

Documentum Foundation Classes

I did a quick search on google looking for Javadoc and couldn’t find it. Likewise, I couldn’t find the DFS WSDL. If anyone can point me to where I can download it over the Internet, it would be appreciated. I know that choice of words is sometimes important but I am stuck on your choice of the phrase: on top of. If one wanted to properly implement security protocols such as SAML and XACML into any ECM product they should support public interfaces that allow for extension of their security model. Creating wrappers on top of simply wouldn’t work…

Few things here. One, I think James and I aren’t communicating ideally on what the DFC is. The javadocs themselves are part of the documentation, outlining all the different java classes that make up the DFC. Not sure where they are publicly available without at least registering on the EMC Developer Network. They are included with every product though, so they aren’t that restricted.

To help explain the DFC, I am punting and using one of EMC’s description of the DFC:

[The] Documentum Foundation Classes (DFC) is the published and supported interface for accessing the functionality of the Documentum platform. DFC exposes the Documentum object model as an object-oriented library for other applications to use. DFC provides Java and component object model (COM) class libraries that expose the functions that drive the Documentum platform.

Basically the DFC is the core interface into the Documentum system. Using it, you can create any application/service that you need. EMC uses it to build all of their Web Applications. The DFC could be used to build a public interface to support SAML, and most likely XACML (no research into this one yet). Once again, choice of words is important and that is why this conversation seems to have to go back and forth.

As for the DFS WSDL, it should be available when D6 is properly released in the next few weeks. Documentum has supported the creation of Web Services prior to D6, but DFS is brand new. Until D6 is out, forget about finding any WSDLs around DFS.