Thursday, July 19, 2007


ECM and Standardizing Authentication

Laurence Hart commented on standardizing authentication that I will dissect...

If you read up on SAML, there are several important considerations. The first thing that SAML supports is functionality related to authentication assertions which gets you the SSO you mentioned. Likewise, there is another concept known as attribute assertion in which attributes are passed dynamically at runtime. In this situation, a remote source will assert at runtime things like who the user is, possibly the roles in which they run, and so on.

One of the general architecture observations of any product is that adding capability to to authentication against an external source is usually straightforward where as the ability to accept attribute information at runtime is either a cakewalk or highly problematic and is dependent upon the underlying architecture of the product and whether it expects to bind to a known datasource such as a copy of its own user store or whether the architecture was thoughtful enough to take it dynamically.

I am confused, if it doesn't require a user store, then why is it making a copy? Bex Huff states that An ECM should store Content, not users which sounds like a sound architecture principle. I really hope that enterprises aren't duplicating all their users just because ECM products require convenience copies.

From what I can tell from Craig Randall, Documentum will be creating Web Services for ECM. There doesn't seem to be a hint as to whether it will be SOAP or REST which could be the first impediment to supporting SAML. If it is SOAP-based then I would assume that Documentum would want to support SAML in the standard manner which would be to include it in a WS-Security header.

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. Maybe you are telling me that the enterprise security folks in the firms you consult at are asleep at the helm? Don't worry, most of my industry peers are...

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. Even if it required custom code, I am more than sure that Craig Randall and others would be willing to provide sample code on how this could be accomplished.

I think you are thinking about this too deeply. 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.

It's it ashame that ECM vendors could sit on the sidelines watching lots of clients struggle with this issue and not even attempt to solve for it? I can say that CRM vendors, ERP vendors, BPM vendors and so on have all addressed this issue. I am really curious why ECM vendors are so freakin lame.

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...

<< Home
| | View blog reactions

This page is powered by Blogger. Isn't yours?