[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [xacml] Contribution: A Brief Introduction to XACML
Sun Microsystems is contributing the attached document, taken from our Open Source implementation of XACML at SourceForge (http://sunxacml.sourceforge.net) to the OASIS XACML TC for possible use as the basis for an XACML Primer. This document itself might be appropriate as an interim Primer until a more extensive document can be prepared. Under OASIS IPR guidelines, the XACML TC is free to modify, extend, or otherwise prepare derivative works based on this document, so long as the derivative work contains the Sun Microsystems copyright notice. Anne Anderson -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692Title: A Brief Introduction to XACML
A Brief Introduction to XACMLLast Updated: March 14, 2003
A Brief Introduction to XACML
In a nutshell, XACML is a general-purpose access control policy
language. This means that it provides a syntax (defined in XML) for
managing access to resources.
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:
Top-Level Constructs: Policy and PolicySetAt the root of all XACML policies is a Policy or a PolicySet. 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. Each XACML policy document contains exactly one Policy or PolicySet root XML tag.
Because a 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. This is
done through a collection of Combining Algorithms. Each algorithm
represents a different way of combining multiple descisions into a single
descision. There are Policy Combining Algorithms (used by PolicySet)
and Rule Combining Algorithms (used by Policy). An example of these is
the Deny Overrides Algorithm, which says that no matter what, if
any evaluation returns Deny, or no evaluation permits, then 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.
Once a Policy has been found and verified to apply to a request,
its Rules are evaluated. A policy can have any number of Rules
which contain the core logic of an XACML policy. The heart of most
Rules is a Condition, which is a boolean function. If the Condition
evaluates to true, then the Rule's Effect (a value of Permit or Deny
that is associated with successful evaluation of the Rule) is
returned. Evaluation of a Condition can also result in an error
(Indeterminate) or discovery that the Condition doesn't apply to the
request (NotApplicable). A Condition can be quite complex, built from
an arbitary nesting of non-boolean functions and attributes.
A Policy resolves attribute values from a request or from some other source through two mechanisms: the AttributeDesignator and the AttributeSelector. An AttributeDesignator lets the policy specify an attribute with a given name and type, and optionally an issuer as well, and then the PDP will look for that value in the request, or elsewhere if no matching values can be found in the request. There are four kinds of designators, one for each of the types of attributes in a request: Subject, Resource, Action, and Environment. Because Subject attributes can be broken into different categories, SubjectAttributeDesignators can also specify a category to look in. AttributeSelectors allow a policy to look for attribute values through an XPath query. A data type and an XPath expression are provided, and these can be used to resolve some set of values either in the request document or elsewhere. Both the AttributeDesignator and the AttributeSelector can return multiple values (since there might be multiple matches in a request or elsewhere), so XACML provides a special attribute type called a Bag. Bags are unordered collections that allow duplicates, and are always what designators and selectors return, even if only one value was matched. In the case that no matches were made, an empty bag is returned, although a designator or selector may set a flag that causes an error instead in this case. Once some Bag of attribute values has been retrieved, they need to be compared in some way to expected values to make access decisions. This is done though a powerful system of functions. Functions can work on any combination of attribute values, and can return any kind of attribute value supported in the system. Functions can also be nested, so you can have functions that operate on the output of other functions, and this hierarchy can be arbitrarily complex. Custom functions can be written to provide an ever richer language for expressing access conditions.
One thing to note when building these hierarchies of functions is that
most functions are defined as working on specific types (like strings
or integers) while designators and selectors always return Bags of
values. To handle this, XACML defines a collection of standard
functions of the form [type]-one-and-only, which accept a bag of
values of the specified type and return the single value if there is
exactly one item in the bag, or an error if there are zero or multiple
values in the bag. This is one of the most common functions that you
will see in a Condition. [type]-one-and-only functions are not needed
in Targets, however, since the PDP automatically applies the matching
function to each element of a bag.
<Policy PolicyId="SamplePolicy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides"> <!-- This Policy only applies to requests on the SampleServer --> <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">SampleServer</AttributeValue> <ResourceAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"/> </ResourceMatch> </Resources> <Actions> <AnyAction/> </Actions> </Target> <!-- 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 --> <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">login</AttributeValue> <ActionAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId="ServerAction"/> </ActionMatch> </Actions> </Target> <!-- Only allow logins from 9am to 5pm --> <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:and"> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-greater-than-or-equal" <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-one-and-only"> <EnvironmentAttributeSelector DataType="http://www.w3.org/2001/XMLSchema#time" AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-time"/> </Apply> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#time">09:00:00</AttributeValue> </Apply> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-less-than-or-equal" <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-one-and-only"> <EnvironmentAttributeSelector DataType="http://www.w3.org/2001/XMLSchema#time" AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-time"/> </Apply> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#time">17:00:00</AttributeValue> </Apply> </Condition> </Rule> <!-- We could include other Rules for different actions here --> <!-- A final, "fall-through" Rule that always Denies --> <Rule RuleId="FinalRule" Effect="Deny"/> </Policy>
Copyright 2003 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]