Monday, July 23, 2007
Understanding ECM Security
I spent some time at a popular Documentum Developer site attempting to understand the Documentum Foundation Classes mentioned by Laurence Hart and now understand why ECM people either can't and/or don't understand the needs of enterprise security concerns...
When Laurence mentioned APIs and extension, I think he may have simply resorted to constraining the solution to whatever was exposed without asking the question of what APIs are missing. Can we acknowledge that there are a distinction between Client APIs and Server APIs? DFC seems analogous to ODBC/JDBC and typically runs in the client tier. Security, in order to be done correctly requires server APIs which run in the address space of Documentum itself which DFC doesn't address.
The issue at hand is that DFC seems like ODBC in that it abstracts the Documentum Query Language. If the grammar for Documentum or any ECM system for that matter doesn't support security constructs then, at best it is possible to write security features but they will be implemented in an insecure manner.
So, the only way I can see this working if Laurence were to take this on would be to remove all ACLs from the server and then extend the DFC by writing a filter that would intercept all requests by applying XACML policy and processing accordingly. The issue though is that another client not using the modified DFC could bypass any security customizations and create a big hole.
Laurence also mentioned that Documentum will be building Documentum Foundation Services on top of Documentum Foundation Classes and believes that support for SAML should be handled by the product. A security professional could conclude two scenarios both of which are bad security:
Laurence, what am I missing? I am curious if all ECM vendors use this notion of query languages and whether it has been standardized across vendors kinda like ANSI-SQL has been standardized across databases? I am curious if all vendors also limit the available APIs to the client tier or do they also support server APIs as well?
There was one additional thing that I am curious about. I never ran across any instructions on how to enable SSL so that the DFC could communicate over a secure channel. Curious how this is accomplished?
Maybe this is an opportunity for Gunnar Peterson to ask the ECM community at large to pay attention to Dealing with Security in an SOA World and help vendors with an architecture overhaul? The beautiful thing is that I can take a peak at Alfresco to see if it suffers from the same design deficiencies or did they do something more progressive. I will post my findings shortly...
| | View blog reactionsWhen Laurence mentioned APIs and extension, I think he may have simply resorted to constraining the solution to whatever was exposed without asking the question of what APIs are missing. Can we acknowledge that there are a distinction between Client APIs and Server APIs? DFC seems analogous to ODBC/JDBC and typically runs in the client tier. Security, in order to be done correctly requires server APIs which run in the address space of Documentum itself which DFC doesn't address.
The issue at hand is that DFC seems like ODBC in that it abstracts the Documentum Query Language. If the grammar for Documentum or any ECM system for that matter doesn't support security constructs then, at best it is possible to write security features but they will be implemented in an insecure manner.
So, the only way I can see this working if Laurence were to take this on would be to remove all ACLs from the server and then extend the DFC by writing a filter that would intercept all requests by applying XACML policy and processing accordingly. The issue though is that another client not using the modified DFC could bypass any security customizations and create a big hole.
Laurence also mentioned that Documentum will be building Documentum Foundation Services on top of Documentum Foundation Classes and believes that support for SAML should be handled by the product. A security professional could conclude two scenarios both of which are bad security:
- Documentum releases DFS with zero support for WS-Security and leave clients on their own
- Documentum releases DFS with SAML and folks bypass this layer
Laurence, what am I missing? I am curious if all ECM vendors use this notion of query languages and whether it has been standardized across vendors kinda like ANSI-SQL has been standardized across databases? I am curious if all vendors also limit the available APIs to the client tier or do they also support server APIs as well?
There was one additional thing that I am curious about. I never ran across any instructions on how to enable SSL so that the DFC could communicate over a secure channel. Curious how this is accomplished?
Maybe this is an opportunity for Gunnar Peterson to ask the ECM community at large to pay attention to Dealing with Security in an SOA World and help vendors with an architecture overhaul? The beautiful thing is that I can take a peak at Alfresco to see if it suffers from the same design deficiencies or did they do something more progressive. I will post my findings shortly...
