A Brief Introduction to XACML

LastUpdated: March 14, 2003

Abstract

·        For more information，https://www.oasis-open.org/committees/xacml/

·        In a nutshell, XACML is a general-purposeaccess control policy language.

o  It provides a syntax (defined in XML) formanaging access to resources.

ABrief Introduction to XACML

·        an OASIS standard describes both  (both written in XML).

o  a policy language

o  an access control decision request/responselanguage

§ The request/response language lets you forma query to ask whether or not a given action should be allowed, and interpretthe result.

·        has standard extension points

o  for defining new functions, data types,combining logic, etc

·        The response always includes an answer about whether the request shouldbe allowed using one offour values:

o  Permit,

o  Deny,

o  Indeterminate (an erroroccurred or some required value was missing, so a decision cannot be made) (不确定)

o  Not Applicable (the request can't beanswered by this service). (待设定)

·        The typical setup is that

1.    someone wants to take some action on aresource.

2.    They will make a request to whatever actuallyprotects that resource (like afilesystem or a web server), which is called a Policy Enforcement Point(PEP).

3.    The PEP will form a request based on the requester's attributes, the resource inquestion, the action, and other information pertaining to the request.

4.    The PEP will then send this request to aPolicy Decision Point (PDP), whichwilllook at the request and somepolicy that applies to the request, andcomeup with an answer about whether access should be granted.

5.    That answeris returned to the PEP, which can then allow or deny access to therequester. Note that thePEP and PDPmight both be contained within a single application, ormight be distributed across several servers.

·        In addition to providing request/responseand policy languages,

o  XACML also provides the other pieces ofthis relationship, namely finding apolicy that applies to a given request and evaluating the request againstthat policy to come up with a yes or no answer.

·        several points in its favour

o  It's standard.

§ By using a standard language, you're usingsomething that has been reviewed by a large community of experts and users, youdon't need to roll your own system each time, and youdon't need to think about all the tricky issues involved indesigning a new language.

§ Plus, as XACML becomes more widelydeployed, it will be easier tointeroperate with other applications using the same standard language.

o  It's generic.

§ This means that rather than trying toprovide access control for a particular environment or a specific kind ofresource, it can beused in anyenvironment.

§ Onepolicy can be written which can then be used by many different kinds ofapplications, and when one common language is used, policy managementbecomes much easier.

o  It's distributed.

§ This means that a policy can be writtenwhich in turn refers to other policieskept in arbitrary locations.

§ The result is that rather than having tomanage a single monolithic policy, different people or groups can managesub-pieces of policies as appropriate,

§ and XACML knows how to correctly combine the results from these differentpolicies into one decision.

o  It's powerful.

§ While there are many ways the base languagecan be extended, many environments will not need to do so. The standardlanguagealready supports a wide varietyof data types, functions, and rulesabout combining the results of different policies.

§ In addition to this, there are alreadystandards groups working on extensions and profiles that will hook XACML intoother standards like SAML and LDAP, which will increase the number of ways thatXACML can be used.

·        Note that XACML is a rich language, so onlysome of its features are shown here. You should look at the specification formore information on all of the features.

TopLevel Constructs: Policy and PolicySet

·        At the root of all XACML policies is aPolicy or a PolicySet.

o  A PolicySet is a container that can hold other Policies or PolicySets,

§ as well as references to policies found in remote locations.

o  A Policy represents a single access controlpolicy, expressed through a set of Rules.

o  Each XACML policy document contains exactlyone Policy or PolicySet root XML tag.

·        reconciling the decisions each makes.

o  Because a Policy or PolicySet may containmultiple policies or Rules, each of which may evaluate to different accesscontrol decisions,

o  XACML needs some way of reconciling the decisions each makes.This is done through a collection ofCombiningAlgorithms.

§ Each algorithm represents a different wayof combining multiple descisions into a single descision.

§ There are Policy Combining Algorithms (usedby PolicySet)

§ and Rule Combining Algorithms (used byPolicy).

o  An example of these is the Deny OverridesAlgorithm,

§ which says that no matter what, if anyevaluation returns Deny, or no evaluation permits, then the final result isalso Deny.

o  These Combining Algorithms are used tobuild up increasingly complex policies, and while there areseven standard algorithms, you canbuild your own to suit your needs.

Targetsand Rules

o  Part of what an XACML PDP needs to do is

o  finda policy that applies to a given request.

o  To do this, XACML provides another featurecalled a Target.

o  A Target is basically

o  aset of simplified conditions for the Subject,

o  Resource and Action that must be met for aPolicySet, Policy or Rule to apply to a given request.

o  These use boolean functions (explained more in the next section) to comparevalues found in a request with those included in the Target.

o  Ifall the conditions of a Target aremet, then its associated PolicySet, Policy, or Rule applies to the request.

o  Inaddition to being a way to check applicability,

o  Target information also provides a way to index policies,

o  which is useful if you need to store manypolicies and then quickly sift through them to find which ones apply.

o  For instance, a Policy might contain aTarget that only applies to requests on a specific service. When a request toaccess that service arrives, the PDP will know where to look for policies thatmight apply to this request because the policiesare indexed based on their Target constraints.

o  Note that a Target may also specify that it applies to any request.

o  Once a Policy has been found and verifiedto apply to a request, its Rules areevaluated.

o  A policy can have any number of Rules whichcontain the core logic of an XACMLpolicy.

o  The heartof most Rules is a Condition, which is a boolean function.

o  If the Condition evaluates to true, thenthe Rule's Effect (a value of Permit orDeny that is associated with successful evaluation of the Rule) isreturned.

o  Evaluation of a Condition can also resultin an error (Indeterminate)

o  or discovery that the Condition doesn't apply to the request(NotApplicable).

o  A Condition can be quite complex, builtfrom an arbitary nesting of non-boolean functions and attributes.

Attributes,Attribute Values, and Functions

o  The currency that XACML deals in isattributes.

o  Attributes are named values of known types

o  that may include an issuer identifier or an issue date and time.

o  Specifically, attributes are characteristics of the Subject,Resource, Action, or Environment in which the access request is made.

o  A user's name, their security clearance,the file they want to access, and the time of day are all attribute values.

o  When a request is sent from a PEP to a PDP,that request is formed almost exclusivelyof attributes(专有排外), and they will be compared toattribute values in a policy to make the access decisions.

o  A Policy resolves attribute valuesfrom a request or from some other source through two mechanisms:

o  the AttributeDesignator

§ An AttributeDesignator lets the policyspecify an attribute with a given name and type, and optionally an issuer aswell, and thenthe PDP will look forthat value in the request, or elsewhere if no matching values can be foundin the request.

§ There are four kinds of designators,

·        one for each of the types of attributes ina request: Subject, Resource, Action,and Environment.

·        Because Subject attributes can be brokeninto different categories, SubjectAttributeDesignators can also specify acategory to look in.

o  the AttributeSelector.

§ AttributeSelectors allow a policy to lookfor attribute values through an XPathquery. A data type and an XPath expression are provided, and these can beused to resolve some set of values either in the request document or elsewhere.

 

o  Both the AttributeDesignator and theAttributeSelector can return multiple values (since there might bemultiple matches in a request or elsewhere),so XACML provides a specialattributetype called a Bag.

o  Bags are unordered collections that allow duplicates, and are always whatdesignators and selectors return, even if only one value was matched.

o  In the case that no matches were made, anempty bag is returned, although a designator or selector may set aflag that causes an error instead inthis case.

o  Once some Bag of attribute values has beenretrieved, they need to be compared in some way to expected values to makeaccess decisions. This is done though a powerful system of functions.

o  Functionscan work on any combination of attribute values, and can return any kind ofattribute value supported in the system.

o  Functions can also be nested, so you can have functions that operate on the output ofother functions, and this hierarchy can be arbitrarily complex.

o  Custom functions can be written to providean ever richer language for expressing access conditions.

o  One thing to note when building these hierarchies of functions is that mostfunctions are definedas working onspecific types (like strings or integers) while designators and selectorsalwaysreturn Bags of values. Tohandle this,

o  XACML defines a collection of standardfunctions of the form

§ [type]-one-and-only, which accept a bag of values of the specifiedtype and return

·        the single value if there is exactly oneitem in the bag,

·        or an error if there are zero or multiplevalues in the bag.

§ This is one of the most common functionsthat you will see in a Condition. [type]-one-and-onlyfunctions are not needed in Targets, however, since the PDP automaticallyapplies the matching function to each element of a bag.

Puttingit Together: An Example Policy

Here is a simple example Policy using those features discussedabove. Its Target says that thePolicy only applies to requests for the server called "SampleServer".

The Policy has a Rulewith a Target that requires an action of "login" and a Condition thatapplies only if the Subject is trying to log in between 9am and 5pm.

Note that this example can be extended to include other Rulesfor different actions. If the first Rule provided here doesn't apply, then adefault Rule is used that alwaysreturns Deny (Rules are evaluated inorder).

<?xml version="1.0" encoding="UTF-8" ?>

<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>