Wednesday, January 09, 2008
Documentum DFS
Thanks to several folks who responded to a previous posting indicating how to add users one at a time to Documentum...
I guess at some level, it is a good thing that there is no way to add/remove a user via DFS as the services approach is fugly. Hopefully, in a future version they won't reinvent the wheel and instead embrace standards such as SPML
In looking at the code snippet that Laurence so graciously posted, this API-like approach is equally fugly for a variety of reasons. I would have expected the notion of user administration to be an API and not parms you pass into generic APIs. I would have also expected that much of it to be in try/catch blocks as you may want an exception thrown if the task can't be completed.
In terms of the model, the notion of DM_User as an identity construct really needs to be separated from the notion of a credential. I have multiple credentials and even multiple personas, but fundamentally I am me. A single user should be able to have multiple credentials like in the real world. I have an employee badge for work, a drivers license, a passport and so on.
The DM_user looks like it expects a password which tells me that Documentum would struggle to participate in a security realm that used some other scheme and approaches such as SAML, Digital Certificates, Information Cards and OpenID could only at best be bastardized to fit into this model.
There should be an API way to indicate how the user was provisioned. I should be able to say that a user was provisioned via LDAP synchronization, vs user console vs programatic. Laurence also mentioned some bug with properly hashing stored passwords which makes me inquisitive if the notion of a salt value is configured somewhere within Documentum. You would hope that it would be different for each installation and not common across companies.
| | View blog reactionsI guess at some level, it is a good thing that there is no way to add/remove a user via DFS as the services approach is fugly. Hopefully, in a future version they won't reinvent the wheel and instead embrace standards such as SPML
In looking at the code snippet that Laurence so graciously posted, this API-like approach is equally fugly for a variety of reasons. I would have expected the notion of user administration to be an API and not parms you pass into generic APIs. I would have also expected that much of it to be in try/catch blocks as you may want an exception thrown if the task can't be completed.
In terms of the model, the notion of DM_User as an identity construct really needs to be separated from the notion of a credential. I have multiple credentials and even multiple personas, but fundamentally I am me. A single user should be able to have multiple credentials like in the real world. I have an employee badge for work, a drivers license, a passport and so on.
The DM_user looks like it expects a password which tells me that Documentum would struggle to participate in a security realm that used some other scheme and approaches such as SAML, Digital Certificates, Information Cards and OpenID could only at best be bastardized to fit into this model.
There should be an API way to indicate how the user was provisioned. I should be able to say that a user was provisioned via LDAP synchronization, vs user console vs programatic. Laurence also mentioned some bug with properly hashing stored passwords which makes me inquisitive if the notion of a salt value is configured somewhere within Documentum. You would hope that it would be different for each installation and not common across companies.
