Jackson Shaw has this to say about authorization via SAML vs XACML. Jonathan Sander follows up with some very good comments about SAML vs XACML.
I really like XACML. Ideally, it should be much more widely used. But when push comes to shove it’s really all about the policy enforcement point (PEP).
SAML can be an easy (relatively) bridging technology that really doesn’t require significant changes to the back-end systems. All that is needed is to create a SAML end point that receives the authentication and creates an authn token appropriate for the services being authenticated. It may also need to provision identity information, but that’s another discussion. The point is the services can still leverage the same authentication token they used before SAML was added.
XACML, on the other hand, will require changes to services to make the appropriate XACML authz queries. In other words, the service needs to become a PEP.
An alternative approach is to pass SAML attribute assertions during the authentication that are converted to updates to a user attribute store (in a DB table or directory). Those attributes are then used for authorization decisions by the service. The same can be done with role information.
You could argue that ABAC and RBAC are not sufficient. But chances are the service you are trying to federate is already ABAC or RBAC based. That and the fact that SAML will be implemented first, makes XACML a hard sell.
Identity Blogger 