RE: [xacml] Re: XACML Policy Model

["Hal Lockhart" <hlockhar@bea.com>]

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

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

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php