XACML -- A No-Nonsense Developer's Guide
Earlier this month, OASIS adopted XACML 1.0 as its first cut at an open standard to help developers build interoperable access controls security for XML documents and end-to-end transactions. In general, XACML (the Extensible Access Control Markup Language) describes two key areas for security -- an access control policy language and a request/response language for two-way communications.
"Its main focus is Authorization and Access Control, but not other aspects of security (although it can be used to trigger entries in an Audit Trail),"IDN was told by OASIS XACML committee co-chair Hal Lockhart (who is also serves in BEA Systems' CTO Office of Security).
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 (AuthN) Policy.
Each XACML policy document contains exactly one Policy or PolicySet root XML tag. A PolicySet is a container that can hold other Policies or PolicySets, as well as references to policies found in remote locations. A Policy represents a single access-control policy, expressed through a set of Rules.
XACML defines and describes "layering" between XML entities to clearly distinguish between security technologies that:
- Create policy;
- Collect the data required for policy evaluation;
- Evaluate policy; and
- Enforce policy.
Why be so granular? One key answer is to enable interoperability for access control approaches, Lockhart said. "While deployed systems may combine two or more of these into a single entity, the architecture maximizes flexibility. For example, a management tool from one vendor could generate policies that are evaluated by a product from another vendor," he said.
One early reaction from a web services software firm was also bullish on the opportunities for simplicity that XACML might provide.
"The XACML standard specifies how policies for information access can be communicated between systems in an XML format. Such a description can allow an application built by a developer to automatically discover the security policies in force to access the resource," said Mukund Balasubramanian, CTO at Infravio, a provider of web services management and security software in Redwood City, Calif.
"Once described, the existence of a comprehensive description of the security capabilities of the underlying systems would enable consolidated and federated security (think single sign-on) and security mapping (or brokering) with only a couple of clicks," Balasubramanian told IDN.
BEA's Lockhart pointed to another possibility, enabled by the combination of SAML and XACML. "A lightweight, or possibly Open Source, policy enforcement components protecting a variety of applications could all consult one or more centralized policy evaluation engines, which use a standardized policy language," he said.
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. XACML utilizes Policy Combining Algorithms (used by PolicySet) and Rule Combining Algorithms (used by Policy).
The Deny Overrides Algorithm is an example of these indicating that no matter what, if any evaluation returns Deny, or no evaluation permits, the final result is also Deny. These Combining Algorithms are used to build up increasingly complex policies, and while there are seven standard algorithms, you can build your own to suit your needs.
The folks at Builder.com have a good description of just how this policy enforcement takes place:
XACML receives a SAML request to determine if access should be granted to a resource based on rule sets, or policies, that are defined by the provider. As opposed to XML encryption, access control information is kept in a physically separate repository that is referenced when a request is made. XPointers and XPaths are defined within tags in the XML resource that inform the parser to check the XACML policies and where to find them.
Drilling Inside XACML -- Where It Wants to Work
Before drilling down into XACML, it's important to keep in mind that the new standard is primarily focused on two aspects:
- To provide a flexible Policy model; and
- To offer access control efficiencies across large scale environments.
For Policy creation/enforcement, XACML brings several features, Lockhart said, including:
- The ability to include almost any property of any of the participants (or component) of the environment, not just the attributes of the requester;
- The ability to use data manipulation and Boolean operators (in combination) to calculate the policy effect. This is especially useful in complex policies with time, location, dollar amount or other multiple dependencies; and
- The ability to protect any sort of resource, with special handling for the important cases of hierarchical namespaces and portions of XML documents.
For scalability, XACML brings:
Implementing XACML with Sample Code
Just how does a developer begin implementing XACML? Is it another "language" developers must learn, or are tools coming to auto-generate the XACML syntax? And what about the policy modeling?
We've got good news and bad news on this one.
Good News -- XACML is intended primarily to be generated by tools, Lockhart told IDN. "Its verbose syntax make it hard to read and tedious to edit for other than very simple policies."
Bad News -- These tools aren't here yet.
Nontheless, SourceForge has provided with the help of Sun Microsystems a template and sample code for using XACML with Java.
Indeed Infravio's Balasubramanian
says the XACML devil will be in the implementation details. "Developers should ensure the application in question actually requires such dynamic discovery and processes the information accordingly." To cope, he suggests "developers should think of XACML in relation to wire-formats such as WS-Security [just] as they do WSDL in relation to SOAP -- description independent of the wire. This makes the architecture elegant and extensible, but [it is] not always absolutely necessary to process dynamically," Balasubramanian told IDN.
Real Code for Implementing XACML
Here is a simple example with sample code to illustrate implementating XACML Policy:
The Target says that the Policy applies only to requests for the server called "SampleServer." The Policy has a Rule with a Target that requires an action of "login" and a Condition that applies only if the Subject is trying to log in between 9am and 5pm.
Note that this example can be extended to include other Rules for different actions. If the first Rule provided here doesn't apply, a default Rule is used that always returns Deny (Note: Rules are evaluated in order).
<!-- This Policy only applies to requests on the SampleServer -->
<!-- Rule to see if we should allow the Subject to login -->
<Rule RuleId="LoginRule" Effect="Permit">
<!-- Only use this Rule if the action is login -->
<!-- Only allow logins from 9am to 5pm -->
<!-- We could include other Rules for different actions here -->
<!-- A final, "fall-through" Rule that always Denies -->
<Rule RuleId="FinalRule" Effect="Deny"/>
Developers can find more info and sample Open Source code for XACML here.
XACML -- The 2003 Tools Outlook
So, for developers who want a bit more help than this, what type of tools might be coming later this year?
"The most obvious type of tool for this purpose," Lockhart told IDN, "is an administrative program. This might present policy to its users in some sort of graphical format, generating and storing them as XACML. Another possibility is programs that generate XACML from other, existing Access Control formats; for example, POSIX ACLs or LDAP ACIs."
Lockhart also noted that a different type of tool might analyze XACML policies and display their effects in some textual or graphical form. He even suggested that in time, "we may see the automated generation of XACML from higher-level expressions of more general classes of policy, such as an organization's overall information security policy." While optimistic about such prospects, Lockhart didn't hazard a guess as to when developers might expect such a tool, nor commit BEA to building such a tool.
But, over the same "long term," Lockhart did suggest that XACML could actually affect the way security policy is built into applications.
"It's unlikely that most applications would have any reason to generate XACML," he said, adding that one of the goals of the XACML authorization language is "to make less work for developers -- not more." XACML would do that, Lockhart explained, by "taking implicit policy which today is very often spread across multiple applications in the form of executable code and bringing it to a central point of administration where it can be more easily be created, modified, made consistent and analyzed for effect."