Re: [xacml-users] Contribution for the XACML Reference list

["massimiliano.masi@gmail.com" <massimiliano.masi@gmail.com>]

Dear Rich, Dear All

See my comments below.

On Mon, Jan 30, 2012 at 8:58 AM, rich levinson <rich.levinson@oracle.com> wrote:
> One suggestion would be to show PolicySet recursion, which I think
> would make the syntax easier to comprehend. Based on my understanding
> of the paper, I assume the PolicySet recursion would look something
> like this, for say, a PolicySet that had a child PolicySet and Policy, where
> the
> child PolicySet had 2  (grand)child Policies:
>
> PDPpolicies ::=
>   {Palg;                   // Top level PolicySet (PS1)
>     target:{};             // Target PS1
>     <Ralg;                 // 1st child Policy    (P1)
>       target:{};           // Target P1
>       rules:(Effect)>      // end Policy P1
>     {Palg;                 // 1st child PolicySet (PS2)
>       target:{};           // Target PS2
>       <Ralg;               // 1st (grand)child Policy (P2)
>         target:{};         // Target P2
>         rules:(Effect)>    // end Policy P2
>       <Ralg;               // 2nd (grand)child Policy (P3)
>         target:{};         // Target P3
>         rules:(Effect)>    // end Policy P3
>     }                      // end PolicySet PS2
>   }                        // end PolicySet PS1
>
> where I have purposely left the combining Palgs and Ralgs and the Effects
> unspecified, and the targets empty. Also the lines rules:(Effect) basically
> mean a single Rule with some specified Effect and no Target or Condition.

The example that you provided is perfect: we will also include it in the full
version of the paper, since as you correctly pointed out, it is explaining
the recursion of PolicySets and policies.

>
> Assuming that is correct, then I think we agree that Table 7 effectively
> specifies the essential XACML syntax, namely recursive PolicySets with
> leaf node Policy elements, each of which can have one or more Rules.
> Similarly, the analysis can be pushed down to the condition where there
> is a recursive Apply element, which I don't think I saw discussed in the
> paper, although in section 6 there was mention of a second parser for
> Rule Condition expressions, which I assume addresses the recursion.

We express the XACML conditions using a separate expression grammar.
If you look at appendix A of the full version [1] we have a syntax
that e.g., is
able to reproduce the following

<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">
 <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
     ....
 </Apply>
 <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal-of">
     ....
  <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">
     ....
  </Apply>
</Apply>

as

and(string-equal(val1, val2), string-equal(val3,val4), and( .. ) )

Note that the expressions syntax in the paper is just a proposal.
Our XACML syntax abstracts from the expression evaluator used,
but we're open to every kind of function evaluation process.




>
> Based on the above understanding, I believe there is pretty close match
> between the grammar you have defined and the implicit grammar that
> is being used in the OpenAz project.

Yes, indeed. We had a look at the example that you provided, and
it seems that there are slight differences (but trivial, and absolutely easy to
change for us) regarding:

* Policy descriptions and ID missing
* Attribute Issuer
* Data Types

>
> In response to your comment that you weren't able to access the
> OpenAz grammar, maybe the following will help:
>
> The OpenAz grammar is described in an email to the OpenAz mailing list:
> http://lists.openliberty.org/pipermail/openaz/2010-July/000075.html
>
> This email shows the OpenAz grammar applied to OAuth 2.0:
> http://lists.openliberty.org/pipermail/openaz/2011-March/000152.html
> The above email also includes instructions to download, build, and run
> OpenAz.

Will do that ASAP! :)



Since we both believe that the syntaxes are rather similar, how can we
proceed now for a possible collaboration?

From the implementation point of view, we could try to work together
for mapping your syntax into our internal objects and data structures.
This work could make more evident the similarity of our syntaxes and
would equip your syntax with a software tool based on solid
mathematical foundations which can be used to prove policy properties
(in a semi-automatic way).

Indeed, from the theoretical point of view, we would like to exploit
the semantics (and the tool) in order to study concepts related to
least privilege, policy similarity and trust elevation.

Ciao,

     Massi

-- 
Massimiliano Masi

http://www.mascanc.net/~max