Evaluating XACML As a Policy Language

Evaluating XACML as a Policy Language

Working Draft 02, 20 March 2003

Document identifier:

wd-xacml-wspleval-02

Location:

Editor:

Anne Anderson, Sun Microsystems <

Contributors:

Abstract:

This document describes a way of evaluating XACML Policy and PolicySet elements in order to extract sets of attributes that conform to the policy.

Status:

This version of the specification is a working draft of the committee. As such, it is expected to change prior to adoption as an OASIS standard.

Committee members should send comments on this specification to the list. Others should subscribe to and send comments to the list. To subscribe, send an email message to with the word "subscribe" as the body of the message.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the XACML TC web page (

Table of Contents

wd-xacml-wspleval-0220 March 2003

1.Introduction...... 3

2.Glossary...... 4

3.Model...... 5

1Semantics of XACML Policy and PolicySet elements...... 5

2Extracting Satisfying Sets from an Origin Policy...... 5

3Evaluating the Destination Policy using Satisfying Sets...... 6

4Constructing a Request or Response...... 7

4.Restricting an XACML Policy...... 8

5.Comparison to [PSCR] ...... 9

6.References...... 10

wd-xacml-wspleval-0220 March 2003

1.Introduction

An XACML Policy or PolicySet element may be evaluated in several ways. In the XACML OASIS Standard Version 1.0 [XACML], an evaluation method is specified for the purpose of determining whether a given set of attributes satisfies a policy. Such an evaluation method is appropriate for a service provider to use prior to granting access to a resource. In this document, a second evaluation method is specified, in which an XACML Policy or PolicySet element is evaluated for the purpose of determining one or more sets of attributes that satisfy the policy. The results of this initial evaluation are then applied to a second policy until a set of attributes satisfying both policies is returned. This second evaluation method is appropriate for a consumer to use in determining how to construct a request to a given provider, and also for a provider to use in determining how to construct a response to a given consumer. For more information about the use-cases and requirements motivating this second model of evaluation, see [WSPLReqs].

This document describes this additional way of evaluating one or more XACML Policy or PolicySet elements.

2.Glossary

The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in [RFC2119].

Destination Policy – a Policy or PolicySet representing the policy associated with the receiving entity in a transaction.

Origin Policy – a Policy or PolicySet representing the policy associated with the initiating entity in a transaction.

Pre-Condition Attributes – Attributes whose values the originator knows ahead of time and considers invariant for this type of transaction.

Satisfying Set - a set of Attributes that satisfies a given policy. The Attributes may be in either of two forms: an Equality, where the named Attribute has a specific value, or a Predicate, where the named Attribute has an associated Predicate.

3.Model

1Semantics of XACML Policy and PolicySet elements

In this model of evaluation, the semantics of the XACML Policy or PolicySet are the same as those specified in [XACML] with one exception. In [XACML], there is no priority or preference attached to the order in which policies, rules, and condition predicates are specified. In this model, policies, rules, and condition predicates are assumed to be specified in order of priority or preference, with more preferred or higher priority elements specified before less preferred or lower priority elements.

2Extracting Satisfying Sets from an Origin Policy

The method of evaluation for this model starts with an Origin Policy – a Policy or PolicySet associated with the originator of a transaction – and a set of Pre-Condition Attributes. Pre-Condition Attributes are those that the originator knows ahead of time and considers invariant for this type of transaction. The set of Pre-Condition Attributes may be empty. The goal of the evaluation is to produce one or more Satisfying Sets – sets of Attribute values or Attribute predicates that satisfy the Origin Policy. Pre-Condition Attributes narrow the Satisfying Sets to those that satisfy the specified values of the Pre-Condition Attributes.

An algorithm follows for extracting Satisfying Sets. The evaluation method need not implement this algorithm directly, but MUST result in the same Satisfying Sets being returned in the same order.

Re-write the initial Policy or PolicySet as a tree of Boolean predicates.

<PolicySet> = PCAlg (<Target>, <Policy or PolicySet>[1], ...<Policy or PolicySet>[n]), where PCAlg depends on the Policy Combining Algorithm as follows:
PermitOverrides = OR
DenyOverrides = AND
FirstApplicable = TBD
Only-one-applicable = TBD

<Policy> = RCAlg (<Target>, <Policy>[1], ...<Policy>[n]), where RCAlg depends on the Rule Combining Algorithm as follows:
PermitOverrides = OR
DenyOverrides = AND
FirstApplicable = TBD

<Rule>: If Effect is “Permit”, <Rule> = AND (<Target>, <Condition>). Otherwise, <Rule> = NOT AND (<Target>, <Condition>).

<Target> = AND (<Subjects>, <Resources>, <Actions>)

<Subjects> = OR (<Subject>[1], <Subject>[2], ..., <Subject>[n])

<Subject> = AND (<SubjectMatch>[1], <SubjectMatch>[2], ... <SubjectMatch>[n])

<Resources> = AND (<ResourceMatch>[1], <ResourceMatch>[2], ... <ResourceMatch>[n])

<Actions> = AND (<ActionMatch>[1], <ActionMatch>[2], ...<ActionMatch>[n])

<AnySubject> = TRUE

<AnyResource> = TRUE

<AnyAction> = TRUE

<Condition>: If FunctionId is a Logical function, then <Condition> = FunctionId (Predicate[1], ..., Predicate[n]). Otherwise, <Condition> is left unevaluated.

<Apply> = If FunctionId is a Logical function, then <Apply> = FunctionId (Predicate[1], ... Predicate[n]). Otherwise, <Apply> is left unevaluated.

Using standard techniques, rewrite the tree as an OR of AND's, preserving the order of the predicates.
Using the PreConditionAttributes, eliminate any AND's for which the values of the PreConditionAttributes make the AND evaluate to FALSE. Eliminate any other AND's that contain incompatible Attribute values.

Each remaining AND predicate represents one set of satisfying Attribute values, with the first set being the most preferred, and the last set being the least preferred.

Note that the resulting AND predicates MAY be complex, since many FunctionIds can't be resolved to a single Attribute value. Certain simplifications can be applied specific to each FunctionId. For example, an AND set that contains

integer-greater-than(SubjectAttrA, 5)

integer-greater-than(SubjectAttrA, 10)

could be simplified to

integer-greater-than(SubjectAttrA, 10)

3Evaluating the Destination Policy using Satisfying Sets

In many cases, the originator of a transaction will want to test the originator's Satisfying Sets against the Destination Policy (policy associated with the destination of the transaction) in order to find a mutually acceptable Satisfying Set.

This is done by constructing a modified XACML Request from a Satisfying Set as follows:

Where the Satisfying Set contains an AttributeDesignator with a value associated using an equality predicate, then a Request Attribute of the correct type is constructed using the specified value.
Where the Satisfying Set contains an AttributeDesignator with a value associated using a more complex predicate, then a special Request Attribute of the correct type is constructed using the complex predicate as the value.

The resulting Request is used to evaluate the Destination Policy according to [XACML], but adding the evaluation of any complex predicate values in special Request Attributes. Note that the evaluation of the Destination Policy may result in a narrowing of certain values in the Satisfying Set in order to make the Attribute Value satisfy both the Origin and the Destination Policy. For example, if the Satisfying Set contains the entry “integer-greater-than(SubjectAttrA , 10)”, and the Destination Policy contains the predicate “integer-equal(SubjectAttrA, 15)”, then the entry in the Satisfying Set must be modified to be “integer-equal(SubjectAttrA, 15)”, since that value satisfies both policies. Such a modification should be considered temporary until one sufficient predicate of the Destination Policy has resulted in a result of Permit. If the predicate being evaluated does not result in Permit, and there is another sufficient predicate, then the Attribute value in the Satisfying Set should be returned to its original value prior to evaluating the next sufficient predicate.

The Destination Policy is evaluated using successive Satisfying Sets starting with the originator's preferred Satisfying Set until either one Satisfying Set results in a “Permit” evaluation of the Destination Policy or until all Satisfying Sets have been exhausted. If no Satisfying Set satisfies the Destination Policy, then there is no mutually compatible policy.

4Constructing a Request or Response

Once the originator has a Satisfying Set that satisfies the Destination Policy, the originator is free to construct the desired Request or Response using any values that satisfy the Satisfying Set. Heuristics can be used to assign specific values to Attributes where the Satisfying Set specifies only an allowed range of values.

4.Restricting an XACML Policy

Several restrictions on the content of XACML Policies may be considered in order to simplify the construction of Satisfying Sets and to simplify the evaluation of a Destination Policy against an XACML Request constructed using Satisfying Sets. None of these restriction is strictly necessary in order to evaluate an XACML Policy according to the model described here, but they may make the evaluation more efficient.

Use only equality predicates in the XACML MatchIds and boolean functions and equality predicates in FunctionIds. Note that many, if not most, real-world policies will use ranges of values (for example, “key-length >= 128”), so this restriction is probably not very useful in practice.
Use only Combining Algorithms that have well-defined Boolean combining semantics.
Construct Origin Policies using Permit-Overrides (with OR combining semantics) and “and” FunctionIds between predicates. This effectively eliminates the need for re-writing the policy into an OR of ANDs, since it is already in that form.

5.Comparison to [PSCR]

[PSCR] should be considered a restricted version of this proposal. The advantage of starting with the unrestricted evaluation model is that the same XACML Policies can be used for both Access Control and for other types of policy decisions. If restrictions need to be applied, then they should be limited to the minimum set necessary to make evaluating XACML Policies for other models tractable.

1.References

[PSCR]T. Moses, Policy statement combination and reduction using XACML, OASIS XACML TC Working Draft 01, 21 March 2003.

[RFC2119]S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, March 1997.

[WSPLReqs]T. Moses, editor, Web-services policy language use-cases and requirements, OASIS XACML TC, 7 March 2003.

[XACML]S. Godik, T. Moses, editors, eXtensible Access Control Markup Language (XACML) Version 1.0, OASIS Standard, 18 February 2003.

2.Acknowledgments

The following individuals were members of the committee during the development of this specification:

3.Revision History

Rev / Date / By Whom / What
wd-01 / 03/18/03 / Anne Anderson / Initial version
wd-02 / 03/19/03 / Anne Anderson / Fix section numbering

4.Notices

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

wd-xacml-wspleval-0220 March 2003