« Ian Howells: With Open Source you can't be half-pregnant | Main | How You Read My Blog »

2007.02.28

Comments

You are correct in that using XACML to apply security to individual documents would be evil. That being said, security should be applied based on role which not only provides a cleaner ECM model but also allows XACML to be cleanly implemented.

One general observation is that the ECM community at large seems to be stuck in the past relative to other domains and have convinced themselves that they are the only ones dealing with millions of elements and the need for sophistacted caching. How can this mindset be broken?

I'll refer back to the post I made back in March of last year. http://newton.typepad.com/content/2006/03/ecm_answers_for.html

"Directory systems are orthogonal to XACML, even though they shouldn’t be. XACML has been designed to provide access control mechanisms to services that do not have their own security control, like new web services. The problem with ECM in using XACML is that their security models are implemented at a lower level and with semantics that may not be as broad as the capabilities of XACML. In addition, XACML does not understand the semantics of the ECM system such as hierarchical structures, roles and mappings for security that can require complex caching schemes to quickly validate content access. We have just been going through an exercise in AIIM iECM to map security services along with IBM and Documentum where we have tried to rationalize these two approaches."

Applying XACML to individual resources (documents or web content) seems an overly complex way of relating XACML to ECM. Defining a role-based interface might work. Also, defining a collection upon which XACML can be applied in relation to operations on items in that collection might also work. I'm happy to hear any proposals you might have.

In the meantime, the standards groups have completely given up on security in general as too hard to rationalize. JSR-283 has settled on a model of applying general policies on content from within the ECM without defining what a policy is. Not quite enough to implement XACML which works by applying the policy outside of the ECM. Will think about this one some more.

You mentioned authentication, how about the ease of adding in externalizable authorization via XACML?

The comments to this entry are closed.