At the root of XACML is a concern with access policies—what XACML refers to as a Policy or a PolicySet. When XACML refers to "policy," it specifically means authorization policy. Each XACML policy document contains exactly one Policy or PolicySet root XML tag. A Policy represents a single access-control policy, expressed through a set of Rules. A Policy is intended to form the basis of an authorization decision. A PolicySet contains a set of Policy or other PolicySet elements and a specified procedure for combining the results of their evaluation. This is the standard means for combining separate policies into a single combined policy. A Rule contains a Boolean expression that can be evaluated in isolation as the basic unit of management; it can be reused in multiple policies.

A few more critical terms used in XACML need to be understood as well. A Target defines a set of resources, subjects, and actions to which a Rule is intended to apply. It is the set of decision requests that a Rule, Policy, or PolicySet is intended to evaluate. An Obligation is an operation specified in a Policy or PolicySet that should be performed in conjunction with the enforcement of an authorization decision. A Condition is an expression that evaluates to True or False or Indeterminate. The Effect is the intended consequence of a satisfied Rule—either Permit or Deny.

Figure 9.9 shows these XACML concepts.

Figure 9.9  Core XACML constructs and their interrelationships.

XACML defines a very granular set of "layers" to:

1. Create policy.

2. Collect the data required for policy evaluation.

3. Evaluate policy.

4. Enforce policy.

This much granularity enables interoperability for a wide variety of access control approaches. It is an architecture that maximizes flexibility.

Because a generic Policy or PolicySet may contain multiple policies or Rules, each of which may evaluate to different access control decisions, XACML needs some way of reconciling the decisions each makes. In XACML, this is done through a collection of Combining Algorithms. Each algorithm represents a different way of combining multiple decisions into a single decision to build up increasingly complex policies. XACML utilizes Policy Combining Algorithms (used by PolicySet) and Rule Combining Algorithms (used by Policy). The set of Combining Algorithms takes the form of deny-overrides, permit-overrides, first-applicable, and only-one-applicable. These are just a few examples, but an arbitrary set can be created from basic primitives.

---

XACML Not Really Ready for Prime Time Yet - XACML is intended primarily to be generated by tools. Its verbose syntax makes it hard to read and tedious to edit for other than very simple policies.

These tools, however, aren't available yet. Nonetheless, a few brave groups have provided a template and sample code for using XACML with Java.

Not many applications will actually require the kind of dynamic discovery provided by XACML. XACML experts suggest that developers think of XACML in relation to wire-formats such as WS-Security just as they do WSDL in relation to SOAP.

The home we expect XACML to find is as the tool to create SAML Policy Decision Points (PDP). PDPs will most likely communicate to back-end policy stores using the XACML access control/policy language.

---

This chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today. Buy this book now.