James McGovern, whose questions in blog comments usually take me a whole additional blog post to answer appropriately, responding to an earlier post on security for Integrated Transactions asks
Would you agree that enterprises need to go beyond just building better authentication mechanisms such as support for SAML and go deeper in terms of authorization? What would it take to get security folks to also add XACML to their list of frequently mentioned acroynms...
I definitely agree with this. Enterprises need to look at authentication, and also authorization, and auditing as well. Plus they need to realize that these security landscapes have fundamentally changed 2 or 3 times in the past decades (OO, web apps, and SOA/Web Services) all require different types of security mechanisms, but many enterprises try in vain to find one silver bullet.
So it is definitely not just about authentication, but the larger point I think (and the one that SAML, WS-Security, WS-Trust, and XACML all to varying degrees help you solve) is how do you get interoperability for security tokens at runtime. A transaction can span dozens of namespaces, technical runtimes, governance and policy zones, etc. So job 1 is to be able to move the tokens and recognize them on the other end (vetting them in the process).
When it comes to authorization, I agree with Butler Lampson that "all trust is local". The aforementioned standards should be able to port the tokens (subjects) used for authorization across domains so that enforcement (which may be authorization) can be done at the endpoint (mediating the subjects access to the object). Part of this is coarse grained versus fine grained authorization.
Now there are some different nuances to how WS-* vs. SAML/XACML accomplishes this. WS-* format is more or less neutral -- a claim by any other name is still a claim. Whereas SAML differentiates authentication, attribute, and authorization authorities. But I don't see this as a big deal, because the endpoint can still enforce how it wants. My take is that SAML/XACML's approach could allow for tool vendors to support (and optimize) their assertions at a more granular level through decomposing authentication, authorization, and attributes. This relates to a point discussed by James and Mark O'Neill way back in 2006.
To James' other point, XACML does some things fundamentally different in describing policy for resources, which makes this really interesting esp. for high value resources. Earlier I made the point that for cases where you need higher assurances, the policy is mapped down to the object level:
The XACML mapping of the subject to authorized resources, conditions, and actions allows for the security policy to be applied to the subject as well as the representation of the object. One example of this in the real world at railroad crossings, normal cars pass straight over the tracks as long as the gate is open and the light is not flashing. School buses, because of their cargo, stop and perform additional visual checks before proceeding
The parents of the kids drive their cars right over the railroad tracks without stopping, other buses (containing presumably less precious cargo) sail right over the railroard tracks, but school buses stop and check - resource, condition, action.
So XACML has great utility for things like this, it would be great if there was more momentum in the tool space so that we could see XACML being built into as many stacks as WS-* and SAML already are. On the plus side all of the aforementioned standards work at the message level, so we are already moving in a more secure direction than relying on network firewalls, SSL, and a prayer.
Comments