Unique Features of XACML

XACML Policy Model and Unique Features of XACML

[Ed Introduction:

This posting snagged from the Discussion List of the OASIS eXtensible Access Control Markup Language (XACML) Technical Committee, provides commentary from Hal Lockhart (BEA Systems) and Anne Anderson (Sun Microsystems), both key contributors to the OASIS Standard.

The XACML TC was chartered "to define a core schema and corresponding namespace for the expression of authorization policies in XML against objects that are themselves identified in XML. There are many proprietary or application-specific access control policy languages, but this means policies cannot be shared across different applications, and provides little incentive to develop good policy composition tools. Many of the existing languages do not support distributed policies, are not extensible, or are not expressive enough to meet new requirements. XACML enables the use of arbitrary attributes in policies, role-based access control, security labels, time/date-based policies, indexable policies, 'deny' policies, and dynamic policies — all without requiring changes to the applications that use XACML."

See the list of XACML References for details.

Date:      Thu, 6 Apr 2006 15:55:29 -0700
From:      Hal Lockhart <hlockhar@bea.com>
To:        Mine Altunay <maltuna@unity.ncsu.edu>
Cc:        xacml@lists.oasis-open.org,
           gbyrd@ncsu.edu, Anne.Anderson@sun.com
Subject:   RE: [xacml] Re: XACML Policy Model

I am not exactly sure what you mean by a formal policy model. Polar Humenn has written a paper on the formal semantics of XACML:

The Formal Semantics of XACML, at http://lists.oasis-open.org/archives/xacml/200310/pdf00000.pdf

In preparing my recent presentation at the RSA Conference on XACML, I reflected on some of the unusual, if not unique features of XACML. I will attempt to summarize them briefly. The strange thing is that the consensus formed around these ideas in around 2002, but I do not remember discussing most of them explicitly at the time.

XACML is request centric. A request of some sort triggers the policy evaluation cycle. The policies in force are potentially applied to any information relating to that request. The fundamental issue is: should access be allowed? XACML allows other actions to be specified (Obligations), but the focus if its design is about getting that yes or no answer.

Consistent with that, XACML policies operate directly on that information. XACML does not introduce any synthetic concepts to define access policies. Many access control systems invent new concepts which are then referenced by policy. For example, in many environments the concept of a Privilege is used as shorthand for one or more Actions on one or more Resources. The Java authorization model takes this one step further by using a Role as a synonym for some set of Privileges.

The main advantage of the XACML approach is that the policy is "all in one place." All the machinery is in the Policies and Policy Sets. It is possible that if the chosen abstractions match the problem space well and the policies are not too complex, the synthetic approach might be easier to use than XACML. But XACML's goal is to be a universal language and enable the use of very complex policies. I also believe XACML is superior for policy maintenance, where the administrator may no longer remember exactly how the policies were set up or it may have been done by someone else.

One unusual feature of XACML, which was discussed at length, is that all the information used by Policies is Attributes. Subjects, Resources, Actions and the Environment just have Attributes. There are no special Attributes that represent the "name" or "identity" of a Subject or a Resource. Attributes can be unique or not. More than one Attribute of say a Subject, can be unique. Or there may be no unique Attribute. Policies don't care. In effect, XACML combines Identity and Capability models into one. This property of XACML is different from other Authorization systems, including SAML, which treats the Name of a Subject differently from other Attributes of that Subject.

The XACML feature that takes the most getting used to is that Policies are dynamically bound to a Situation. Other access control systems, such as Permissions, ACLs, or ACIs statically associate the policy representation to they thing it applies to, usually a Resource, such as a file. Using XACML, the set of Attributes associated with the request determine what Policies apply. Two very similar requests might be controlled by completely different Policies. Although the term Situation was not introduced until 2005, the concept has been a key one all along.

Because the Situation determines what Policies apply and because XACML Policies can be quite complex and expensive to compute (or even to gather the required data), a method was required to find the Policies that apply without evaluating all policies on every request. The solution chosen was XACML's two stage evaluation strategy. First the Target is evaluated. The details of this are left implementation-specific but the idea is that some sort of efficient indexing is used to find a small set of Policies that may apply to the given Situation. Then this set of Policies is fully evaluated to determine which ones, if any, actually do apply.

Obviously one direct consequence of this is that two or more Policies may be applicable. If some of them say Permit, while others say Deny, a method is needed to determine the result. This led to the concept of a Policy Combining Algorithm. (Since Policies can contain multiple Rules there is also a Rule Combining Algorithm.) While most security practitioners strongly favor a combining Algorithm of "Deny Overrides", there was a desire to make XACML more general and any one of a number of different algorithms may be chosen.

Policy Combining Algorithms are useful for another reason. In a large organization it is not unusual to have multiple parties creating Policies which may apply to the same resources. For example, the corporate audit department may define Policies to all web sites involving e-commerce and the online sales department may define Policies that apply to a particular set of web servers. These groups are not working against each other, but it may be inconvenient for them to closely cooperate in their work on a day to day basis. XACML allows each to write Policies independently in the most natural form and Policy Combining will resolve any conflicts.

In XACML, the rules for evaluating Conditions do not constrain the order of evaluation. This is important for efficiency. Evaluation can attempt to avoid using data that is expensive or inconvenient to obtain or doing expensive calculations, if the result can be determined without them. However, some people have a requirement for complete evaluation, for example to make the return of Obligations deterministic. This can be done by breaking up the Condition into multiple rules and using on of the Rule Combining Algorithms especially designed for this purpose.

Hal

From:      Anne Anderson [mailto:Anne.Anderson@sun.com]
Sent:      Thursday, March 09, 2006 12:03 PM
To:        Mine Altunay
Cc:        xacml@lists.oasis-open.org; gbyrd@ncsu.edu
Subject:   [xacml] Re: XACML Policy Model

XACML does not fall neatly into any particular logical category. At the most abstract level, very roughly, an XACML policy is a Boolean combination of predicates, each of which is a functional constraint on the values of a set of variables being evaluated (or on the results of other functional constraints and transformation functions).

The standard functional constraints include simple Boolean comparison functions (X > 5, X == "abc"), higher-order functions (all/at least one/... values of X Boolean-function-variable all/at least one/... values in {"abc", "xyz"}, etc.), regular expression matches, type-specific matches (such as matching X500 Distinguished Names), etc. The values used in the constraint functions may themselves be other variables, results of other constraint functions or of various arithmetic and transformation functions (X > (5 + Y), toUpperCase(X) == "ABC"), etc. Users are free to define new functional constraints, but XACML itself does not provide a language for expressing functions: users must describe/implement the semantics of the function and then reference it using a unique identifier. The XACML language itself deals with evaluating parameters to the function and dealing with the results of evaluating the function. The variables used in constraint and other functions can be pointers into XML documents or discrete named variables.

XACML's "combining algorithms", used to combine results from sub-policies, can be arbitrarily complex. The standard ones include deny-overrides (roughly Boolean AND) and permit-overrides (roughly Boolean XOR), but users are free to write more complex algorithms that might take into account parameters associated with each sub-policy, for example. The standard combining algorithms are not simple Boolean operators because we need to handle 4 types of values resulting from policy evaluation: true and false, but also "Indeterminate" (error), and

"NotApplicable" (the policy or rule does not apply to the supplied set of variables).

Perhaps others on the list can elaborate or be more specific (or more correct :-)

Regards, Anne Anderson

Mine Altunay wrote On 03/09/06 10:52,:
> Dear list
> Is there a published paper explaining the formal policy model of XACML.
> For example, the formal specification of the rules that can be specified
> by XACML.
>
> I have read and worked with Sun's implementation of XACML engine. I am
> also fairly familiar with simple policy statements that can be expressed
> within XACML. However, my experiece is far from being sufficient to
> understand the underlying policy model completely.
>
> A formal policy model would make it very much easier for me to grasp the
> finer points of XACML, and how we can use/enhance XACML for representing
> complicated rule sets.
>
> I have also seen the OASIS Technical Committee for Policy Model.
> However, I could not download any of the posted documents due to 404
> errors. I beleve this committee is already closed. I would appreciate to
> know if they published reports from this committee somewhere else
>
> Any help is highly appreciated Best Regards,
> Mine Altunay
>
> Computer Eng Dept
> NC State Univ

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

Prepared by Robin Cover for The XML Cover Pages archive.

SEARCH Advanced Search ABOUT Site Map CP RSS Channel Contact Us Sponsoring CP About Our Sponsors NEWS Cover Stories Articles & Papers Press Releases CORE STANDARDS XML SGML Schemas XSL/XSLT/XPath XLink XML Query CSS SVG TECHNOLOGY REPORTS XML Applications General Apps Government Apps Academic Apps EVENTS LIBRARY Introductions FAQs Bibliography Technology and Society Semantics Tech Topics Software Related Standards Historic	Unique Features of XACML XACML Policy Model and Unique Features of XACML [Ed Introduction: This posting snagged from the Discussion List of the OASIS eXtensible Access Control Markup Language (XACML) Technical Committee, provides commentary from Hal Lockhart (BEA Systems) and Anne Anderson (Sun Microsystems), both key contributors to the OASIS Standard. The XACML TC was chartered "to define a core schema and corresponding namespace for the expression of authorization policies in XML against objects that are themselves identified in XML. There are many proprietary or application-specific access control policy languages, but this means policies cannot be shared across different applications, and provides little incentive to develop good policy composition tools. Many of the existing languages do not support distributed policies, are not extensible, or are not expressive enough to meet new requirements. XACML enables the use of arbitrary attributes in policies, role-based access control, security labels, time/date-based policies, indexable policies, 'deny' policies, and dynamic policies — all without requiring changes to the applications that use XACML." See the list of XACML References for details. Date: Thu, 6 Apr 2006 15:55:29 -0700 From: Hal Lockhart <hlockhar@bea.com> To: Mine Altunay <maltuna@unity.ncsu.edu> Cc: xacml@lists.oasis-open.org, gbyrd@ncsu.edu, Anne.Anderson@sun.com Subject: RE: [xacml] Re: XACML Policy Model I am not exactly sure what you mean by a formal policy model. Polar Humenn has written a paper on the formal semantics of XACML: The Formal Semantics of XACML, at http://lists.oasis-open.org/archives/xacml/200310/pdf00000.pdf In preparing my recent presentation at the RSA Conference on XACML, I reflected on some of the unusual, if not unique features of XACML. I will attempt to summarize them briefly. The strange thing is that the consensus formed around these ideas in around 2002, but I do not remember discussing most of them explicitly at the time. XACML is request centric. A request of some sort triggers the policy evaluation cycle. The policies in force are potentially applied to any information relating to that request. The fundamental issue is: should access be allowed? XACML allows other actions to be specified (Obligations), but the focus if its design is about getting that yes or no answer. Consistent with that, XACML policies operate directly on that information. XACML does not introduce any synthetic concepts to define access policies. Many access control systems invent new concepts which are then referenced by policy. For example, in many environments the concept of a Privilege is used as shorthand for one or more Actions on one or more Resources. The Java authorization model takes this one step further by using a Role as a synonym for some set of Privileges. The main advantage of the XACML approach is that the policy is "all in one place." All the machinery is in the Policies and Policy Sets. It is possible that if the chosen abstractions match the problem space well and the policies are not too complex, the synthetic approach might be easier to use than XACML. But XACML's goal is to be a universal language and enable the use of very complex policies. I also believe XACML is superior for policy maintenance, where the administrator may no longer remember exactly how the policies were set up or it may have been done by someone else. One unusual feature of XACML, which was discussed at length, is that all the information used by Policies is Attributes. Subjects, Resources, Actions and the Environment just have Attributes. There are no special Attributes that represent the "name" or "identity" of a Subject or a Resource. Attributes can be unique or not. More than one Attribute of say a Subject, can be unique. Or there may be no unique Attribute. Policies don't care. In effect, XACML combines Identity and Capability models into one. This property of XACML is different from other Authorization systems, including SAML, which treats the Name of a Subject differently from other Attributes of that Subject. The XACML feature that takes the most getting used to is that Policies are dynamically bound to a Situation. Other access control systems, such as Permissions, ACLs, or ACIs statically associate the policy representation to they thing it applies to, usually a Resource, such as a file. Using XACML, the set of Attributes associated with the request determine what Policies apply. Two very similar requests might be controlled by completely different Policies. Although the term Situation was not introduced until 2005, the concept has been a key one all along. Because the Situation determines what Policies apply and because XACML Policies can be quite complex and expensive to compute (or even to gather the required data), a method was required to find the Policies that apply without evaluating all policies on every request. The solution chosen was XACML's two stage evaluation strategy. First the Target is evaluated. The details of this are left implementation-specific but the idea is that some sort of efficient indexing is used to find a small set of Policies that may apply to the given Situation. Then this set of Policies is fully evaluated to determine which ones, if any, actually do apply. Obviously one direct consequence of this is that two or more Policies may be applicable. If some of them say Permit, while others say Deny, a method is needed to determine the result. This led to the concept of a Policy Combining Algorithm. (Since Policies can contain multiple Rules there is also a Rule Combining Algorithm.) While most security practitioners strongly favor a combining Algorithm of "Deny Overrides", there was a desire to make XACML more general and any one of a number of different algorithms may be chosen. Policy Combining Algorithms are useful for another reason. In a large organization it is not unusual to have multiple parties creating Policies which may apply to the same resources. For example, the corporate audit department may define Policies to all web sites involving e-commerce and the online sales department may define Policies that apply to a particular set of web servers. These groups are not working against each other, but it may be inconvenient for them to closely cooperate in their work on a day to day basis. XACML allows each to write Policies independently in the most natural form and Policy Combining will resolve any conflicts. In XACML, the rules for evaluating Conditions do not constrain the order of evaluation. This is important for efficiency. Evaluation can attempt to avoid using data that is expensive or inconvenient to obtain or doing expensive calculations, if the result can be determined without them. However, some people have a requirement for complete evaluation, for example to make the return of Obligations deterministic. This can be done by breaking up the Condition into multiple rules and using on of the Rule Combining Algorithms especially designed for this purpose. Hal From: Anne Anderson [mailto:Anne.Anderson@sun.com] Sent: Thursday, March 09, 2006 12:03 PM To: Mine Altunay Cc: xacml@lists.oasis-open.org; gbyrd@ncsu.edu Subject: [xacml] Re: XACML Policy Model XACML does not fall neatly into any particular logical category. At the most abstract level, very roughly, an XACML policy is a Boolean combination of predicates, each of which is a functional constraint on the values of a set of variables being evaluated (or on the results of other functional constraints and transformation functions). The standard functional constraints include simple Boolean comparison functions (X > 5, X == "abc"), higher-order functions (all/at least one/... values of X Boolean-function-variable all/at least one/... values in {"abc", "xyz"}, etc.), regular expression matches, type-specific matches (such as matching X500 Distinguished Names), etc. The values used in the constraint functions may themselves be other variables, results of other constraint functions or of various arithmetic and transformation functions (X > (5 + Y), toUpperCase(X) == "ABC"), etc. Users are free to define new functional constraints, but XACML itself does not provide a language for expressing functions: users must describe/implement the semantics of the function and then reference it using a unique identifier. The XACML language itself deals with evaluating parameters to the function and dealing with the results of evaluating the function. The variables used in constraint and other functions can be pointers into XML documents or discrete named variables. XACML's "combining algorithms", used to combine results from sub-policies, can be arbitrarily complex. The standard ones include deny-overrides (roughly Boolean AND) and permit-overrides (roughly Boolean XOR), but users are free to write more complex algorithms that might take into account parameters associated with each sub-policy, for example. The standard combining algorithms are not simple Boolean operators because we need to handle 4 types of values resulting from policy evaluation: true and false, but also "Indeterminate" (error), and "NotApplicable" (the policy or rule does not apply to the supplied set of variables). Perhaps others on the list can elaborate or be more specific (or more correct :-) Regards, Anne Anderson Mine Altunay wrote On 03/09/06 10:52,: > Dear list > Is there a published paper explaining the formal policy model of XACML. > For example, the formal specification of the rules that can be specified > by XACML. > > I have read and worked with Sun's implementation of XACML engine. I am > also fairly familiar with simple policy statements that can be expressed > within XACML. However, my experiece is far from being sufficient to > understand the underlying policy model completely. > > A formal policy model would make it very much easier for me to grasp the > finer points of XACML, and how we can use/enhance XACML for representing > complicated rule sets. > > I have also seen the OASIS Technical Committee for Policy Model. > However, I could not download any of the posted documents due to 404 > errors. I beleve this committee is already closed. I would appreciate to > know if they published reports from this committee somewhere else > > Any help is highly appreciated Best Regards, > Mine Altunay > > Computer Eng Dept > NC State Univ -- 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-1692 Prepared by Robin Cover for The XML Cover Pages archive.