Tuesday, July 24, 2007
Thoughts on ECM and Security - Part Alfresco
Laurence Hart has been gracious in helping me understand Limitations of ECM Products with the focus on Documentum. I figured I wanted to understand if all ECM products have the same design flaws and have decided to analyze Alfresco to see how it measures up...
Alfresco seems more aggressive in terms of supporting ECM specific standards such as JSR-170. I didn't have the opportunity to dig into the codebase as to whether they could expose documents via RSS and/or ATOM nor did I get to determine whether they fully support WebDAV including functionality such as locking but hope to analyze this later.
In terms of the design of Alfreso, it feels a lot like Documentum only in that it was written in a modern language. Missing from Alfresco is the notion of the usual Core J2EE patterns as the code base, while functional could do with some major refactoring.
Bex Huff recently commented that an ECM Should Store Content, Not Users which Alfresco is also guilty of repeating. It seems as if vendors have figured out a slick response when enterprise architects inquire in this space by mentioning that they can authenticate against external stores which is semantically different than binding at runtime and gathering all information without requiring a local copy. I hope my industry peers start separating out their questions into user stores vs authentication.
In terms of the ability to easily inject XACML and externalizing authorization, it also suffers from the same problem that Documentum does but for different reasons. The issue at hand is that permissions checking in Alfresco isn't centralized as access control checks are littered through different classes. Since Alfresco has a great relationship with Liferay, I would suggest that a future implementation refactor to something similar to com.liferay.portal.kernel.security.permission.PermissionChecker which is a great way to approach extensible security.
Even though they have committed the sins of duplicating user stores, it does seem that they are well-positioned to support protocols such as SPML to allow identity management tools to remotely provision/deprovision users without resorting to arcane syncronization routines.
In terms of supporting SAML, I believe based on current documentation that Alfresco does have an advantage over Documentum. They leverage JAAS and have the notion of an abstract authentication component that can be extended. It would be very easy to connect this to BEA Weblogic and their notion of an Identity Asserter to allow the container to handle some of the SAML interaction while Alfresco focuses in on the JAAS aspects.
In terms of other ways to SSO, they also support the Kerberos SPNEGO protocol which is useful in shops that run Active Directory which 499 of the Fortune 500 run (Sun Microsystems is the oddball). Likewise, the design does seem better than other products in that they also assume the ability to plugin other search providers. I am still researching whether they have the ability to plugin other compression routines and to externalize transformations to third-party hardware providers such as DataPower...
| | View blog reactionsAlfresco seems more aggressive in terms of supporting ECM specific standards such as JSR-170. I didn't have the opportunity to dig into the codebase as to whether they could expose documents via RSS and/or ATOM nor did I get to determine whether they fully support WebDAV including functionality such as locking but hope to analyze this later.
In terms of the design of Alfreso, it feels a lot like Documentum only in that it was written in a modern language. Missing from Alfresco is the notion of the usual Core J2EE patterns as the code base, while functional could do with some major refactoring.
Bex Huff recently commented that an ECM Should Store Content, Not Users which Alfresco is also guilty of repeating. It seems as if vendors have figured out a slick response when enterprise architects inquire in this space by mentioning that they can authenticate against external stores which is semantically different than binding at runtime and gathering all information without requiring a local copy. I hope my industry peers start separating out their questions into user stores vs authentication.
In terms of the ability to easily inject XACML and externalizing authorization, it also suffers from the same problem that Documentum does but for different reasons. The issue at hand is that permissions checking in Alfresco isn't centralized as access control checks are littered through different classes. Since Alfresco has a great relationship with Liferay, I would suggest that a future implementation refactor to something similar to com.liferay.portal.kernel.security.permission.PermissionChecker which is a great way to approach extensible security.
Even though they have committed the sins of duplicating user stores, it does seem that they are well-positioned to support protocols such as SPML to allow identity management tools to remotely provision/deprovision users without resorting to arcane syncronization routines.
In terms of supporting SAML, I believe based on current documentation that Alfresco does have an advantage over Documentum. They leverage JAAS and have the notion of an abstract authentication component that can be extended. It would be very easy to connect this to BEA Weblogic and their notion of an Identity Asserter to allow the container to handle some of the SAML interaction while Alfresco focuses in on the JAAS aspects.
In terms of other ways to SSO, they also support the Kerberos SPNEGO protocol which is useful in shops that run Active Directory which 499 of the Fortune 500 run (Sun Microsystems is the oddball). Likewise, the design does seem better than other products in that they also assume the ability to plugin other search providers. I am still researching whether they have the ability to plugin other compression routines and to externalize transformations to third-party hardware providers such as DataPower...
