SCDJWS Study Guide: XML Security
Although SAML provides a mechanism for making authentication and authorization assertions and conveying these assertions using XML protocol, a vocabulary is also needed for expressing the rules needed to make authorization decisions. One XML vocabulary created specifically for expressing authorization rules is the XML Access Control Markup Language.
XACML stands for Extensible Access Control Markup Language, and its primary goal is to provide access control mechanisms and policies in XML syntax. Regarded as another pioneering effort from OASIS, XACML is expected to complement SAML in providing authentication and authorization capabilities to XML documents and Web services in particular.
A standard access control language results in lower costs because there is no need to develop an application-specific access control language or write the access control policy in multiple languages. Plus, system administrators need to understand only one language. With XACML, it is also possible to compose access control policies from the ones created by different parties.
XACML strives to provide fine-grained control over authorization privileges that can exist over a resource (such as read, write, create, delete and so on), based on specific criteria such as the following:
- Subject identity. (Example: Only subscribers can access the credit card password.)
- Subject group. (Example: Only senior managers are entitled to view the financial statement.)
- Authentication mechanism. (Example: Requests should be authenticated using XML Dsig.)
- Protocol over which the request is made. (Example: Credit card statements can be viewed only over HTTPS.)
XACML paves the way for incorporating security access policies into confidential XML documents in a standard manner. It provides XML with "...a sophisticated access control mechanism that enables the initiator not only to securely browse XML documents, but also to securely update each document element..." (per the specifications).
XACML is an OASIS standard that describes both a policy language and an access control decision request/response language (both written in XML). The policy language is used to describe general access control requirements, and has standard extension points for defining new functions, data types, combining logic, etc. The request/response language lets you form a query to ask whether or not a given action should be allowed, and interpret the result. The response always includes an answer about whether the request should be allowed using one of four values: Permit, Deny, Indeterminate (an error occurred or some required value was missing, so a decision cannot be made) or Not Applicable (the request can't be answered by this service).
The typical setup is that someone wants to take some action on a resource. They will make a request to whatever actually protects that resource (like a filesystem or a web server), which is called a Policy Enforcement Point (PEP). The PEP will form a request based on the requester's attributes, the resource in question, the action, and other information pertaining to the request. The PEP will then send this request to a Policy Decision Point (PDP), which will look at the request and some policy that applies to the request, and come up with an answer about whether access should be granted. That answer is returned to the PEP, which can then allow or deny access to the requester. Note that the PEP and PDP might both be contained within a single application, or might be distributed across several servers. In addition to providing request/response and policy languages, XACML also provides the other pieces of this relationship, namely finding a policy that applies to a given request and evaluating the request against that policy to come up with a yes or no answer.
There are many existing proprietary and application-specific languages for doing this kind of thing but XACML has several points in its favor:
- It's standard. By using a standard language, you're using something that has been reviewed by a large community of experts and users, you don't need to roll your own system each time, and you don't need to think about all the tricky issues involved in designing a new language. Plus, as XACML becomes more widely deployed, it will be easier to interoperate with other applications using the same standard language.
- It's generic. This means that rather than trying to provide access control for a particular environment or a specific kind of resource, it can be used in any environment. One policy can be written which can then be used by many different kinds of applications, and when one common language is used, policy management becomes much easier.
- It's distributed. This means that a policy can be written which in turn refers to other policies kept in arbitrary locations. The result is that rather than having to manage a single monolithic policy, different people or groups can manage sub-pieces of policies as appropriate, and XACML knows how to correctly combine the results from these different policies into one decision.
- It's powerful. While there are many ways the base language can be extended, many environments will not need to do so. The standard language already supports a wide variety of data types, functions, and rules about combining the results of different policies. In addition to this, there are already standards groups working on extensions and profiles that will hook XACML into other standards like SAML and LDAP, which will increase the number of ways that XACML can be used.
Every enterprise has a need to secure resources
accessed by employees, partners, and customers. For example, browser
based access to portals which aggregate resources (web pages,
applications, services, etc.) are typical in today's enterprises.
Clients send requests to servers for resources, but before a server can
return that resource it must determine if the requester is authorized
to use the resource. This is where XACML fits in. XACML provides a
policy language which allows administrators to define the access
control requirements for their application resources. The language and
schema support include data types, functions, and combining logic which
allow complex (or simple) rules to be defined. XACML also includes an
access decision language used to represent the runtime request for a
resource. When a policy is located which protects a resource, functions
compare attributes in the request against attributes contained in the
policy rules ultimately yielding a permit or deny decision.
When a client makes a resource request upon a server, the entity charged with access control by enforcing authorization is called the Policy Enforcement Point. In order to enforce policy, this entity will formalize attributes describing the requester at the Policy Information Point and delegate the authorization decision to the Policy Decision Point. Applicable policies are located in a policy store and evaluated at the Policy Decision Point, which then returns the authorization decision. Using this information, the Policy Enforcement Point can deliver the appropriate response to the client.
An administrator creates policies in the XACML language. The key top-level element is the PolicySet which aggregates other PolicySet elements or Policy elements. The Policy element is composed principally of Target, Rule and Obligation elements and is evaluated at the Policy Decision Point to yield and access decision. Since multiple policies may be found applicable to an access decision, (and since a single policy can contain multiple Rules) Combining Algorithms are used to reconcile multiple outcomes into a single decision.
Standard Combining Algorithms are defined for Deny-Overrides, Permit-Overrides, First Applicable, and Only-One Applicable outcomes. The Target element is used to associate a requested resource to an applicable Policy. It contains conditions that the requesting Subject, Resource, or Action must meet for a Policy Set, Policy, or Rule to be applicable to the resource. The Target includes a build-in scheme for efficient indexing/lookup of Policies. Rules provide the conditions which test the relevant attributes within a Policy. Any number of Rule elements may be used each of which generates a true or false outcome. Combining these outcomes yields a single decision for the Policy, which may be "Permit", "Deny", "Indeterminate", or a "NotApplicable" decision.
Attributes provide the typed values that represent both a resource requester and the Policy's condition predicates. When describing the requester, attributes may include an issue date and time, issuer identification, and optionally are contained in the Subject, Environment, Resource and Action elements of the access request. The Attribute Designator element is used to retrieve attribute values from a request by specifying the name, type, and issuer of attributes. The SubjectAttributeDesignator, ResourceAttributeDesignator, ActionAttributeDesignator, and EnvironmentAttributeDesignator each retrieves attributes from the respective elements in the request. An AttributeSelector element is used to locate request attributes using XPATH queries. Since queries can return collections of attributes (all of the same primitive type) they are placed in a Bag. Functions are then used to compare attributes contained within a Bag.
- An XML vocabulary for expressing authorization rules
- An XML vocabulary for expressing a variety of conditions to be used in creating rules.
- How rules are to be combined and evaluated
- A means for creating policy statements, a collection of rules applicable to a subject.
- The XACML draft uses the SAML definitions for subjects and actions.
- XACML defines rules as targets, effects and conditions.
- A target includes resources, subjects and actions, as defined in SAML.
- An effect is either "Allow" or "Deny".
- Conditions are predicates and attributes defined in the XACML specification.
To make this concrete, consider the following rule taken from the XACML draft. This example will grant read access to records documents on the medico web site only if the SAML subject is the patient:
<Rule RuleId="//medico.com/rules/rule3" Effect="Permit">
<AttributeDesignator AttributeName="patientName" />
Example 14 - XACML Access Rule
Rules may be combined, and the XACML includes a specification on how this is done. In addition, rules may be collected into policy statements, including a target, rule-combining algorithm specification, a set of rules, and obligations. The target of a policy statement is used to determine where the policy is applicable and may be stated explicitly or derived from the targets of the policy rules. An obligation is an action to be performed once the authorization decision is complete. An example is sending a patient a notification email each time his or her record is accessed.