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...
| | View blog reactions- 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.
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.
- 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.
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.
- 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.
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 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.
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...
- 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.
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.
- 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.
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.
- 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.
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.
- 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.
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...
