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

[rich levinson <rich.levinson@oracle.com>]

Hi Massimiliano (and other authors),

Thanks for getting back on my questions. Your answers did enable me
to understand the syntax and to go thru the rest of the paper.
(I am cc'ing the openaz mail list as well, as people interested in that
project may well be interested in this discussion as well.)

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.

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.

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.

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.

For comparison purposes, which I think also shows the similarities between
your formalized grammar and the "line at a time" grammar of OpenAz, which
was developed out of the necessity of managing the test policies (i.e. the xml
maintenance proved to be too much to manually maintain, especially when
going back to an old Policy and trying to figure out what it was doing.), here
is a quick attempt to represent the Policy you have in Listing 2:

      Policy (P1,in:x) ( cb:po id:Listing-2-Policy )
        Target(Policy)
          TS (sub-role,"medical doctor" dt:string mtId:str-eq fnId:! issuer:! mbp:f )
           + (sub-purpose,"TREATMENT" dt:string mtId:str-eq fnId:! issuer:! mbp:f )
          TR (res-id,"34133-9" dt:anyURI mtId:uri-eq fnId:! issuer:! mbp:f )
        Rules(Policy)
          Rule ( ef:Permit id:ReadRule )
            Target(Rule)
              TA (act-id,"Read" dt:string mtId:str-eq fnId:! issuer:! mbp:f )
            Condition(Rule)
              TS (sub-perm,"PRD-003" dt:string mtId:str-eq fnId:! issuer:! mbp:f )
               + (sub-perm,"PRD-005" dt:string mtId:str-eq fnId:! issuer:! mbp:f )
               + (sub-perm,"PRD-010" dt:string mtId:str-eq fnId:! issuer:! mbp:f )
               + (sub-perm,"PRD-016" dt:string mtId:str-eq fnId:! issuer:! mbp:f )
          Rule ( ef:Deny id:Final )
            Target(Rule)

I think you will find that the syntactic structure is basically the same, which
I attribute to the fact that the XML itself has this implicit syntax and these
abbreviated syntaxes basically strip out the XML overhead.

Let me briefly explain how the overall OpenAz system works with this
"XACML Shorthand" as we have coined a term for it:

1. There is a class OpenAzPolicyReader, which reads the xacml shorthand syntax
   and generates an XML PolicySet based on it. The PolicySet can then be read in
   by SunXACML PDP at startup and things are ready to go.
   http://openaz.svn.sourceforge.net/viewvc/openaz/test/doc/test/policies/OpenAzPolicyReader.html
   
2. The way the XML is generated is by using a class called XacmlPolicyBuilder:
   http://openaz.svn.sourceforge.net/viewvc/openaz/test/doc/test/policies/XacmlPolicyBuilder.html

The interesting thing is that the XML, itself, is really a non-essential part of this
process. XacmlPolicyBuilder totally operates on the internal SunXacml objects,
and only when all the objects are completely assembled, is the PolicySet sericalized
to XML. However, what SunXacml does when it loads the Policy is parse the XML
and produce exactly the same object structure that was used to serialize the
PolicySet in the first place.

Similarly, on the PEP side, we allow any objects to be submitted for an authorization
call, and mappers extract the XACML Attributes out of these objects and put them
in an object model using the OpenAz AzApi, which then submits the AzRequestContext
to a wrapper for the SunXacml PDP. This wrapper builds the SunXacml objects for
submitting an API request to the PDP, and again no XML is required. However, for
demo purposes, we do serialize the request and response to xml to put in the log
to show the activity in std XACML XML form.

As indicated above, this approach was primarily done to ease the burden of
maintaining the test policies, however, it is recognized that this approach may
also be used for devekoping Policy design tools.

The OpenAz syntax is intended only to be an "intermediate syntax" between a GUI
that presents a user-friendly higher level perspective, such as:

Grant <users> Permission <resource-id> <resource-type><action-id>

where presumably the above syntax would be parsed into the line at a time xacml shorthand,
which could then be used to generate policies in XACML XML or some other engine-specific
format.

One other point of commonality which I will not explore in any depth now is that
I believe your MatchId construct is similar in concept and scope to the OpenAz
AttributeMatchExpression, which is the fundamental unit around which the OpenAz
Xacml policies are based.

    Thanks again for your help for understanding your paper,
    Rich

On 1/19/2012 5:44 AM, massimiliano.masi@gmail.com wrote:

Dear Rich,

Thanks a lot for your mail. Sorry for the late answer, but I was
abroad after christmas (a long week in the www.ihe.net connectathon
event). Please find my comments below.

On Tue, Jan 10, 2012 at 7:34 AM, rich levinson <rich.levinson@oracle.com> wrote:

p13, table 1: (actually also tables 2,3) Personally, I think the title of
table
should be "Policy Set Evaluation" (singular) instead of the current
"Policy Sets Evaluation" (plural). As I look at the 3 columns, I see the
possible outcomes of evaluation of one Target, multiple Policy or
PolicySet elements within a single PolicySet, and a single value in
column 3 for the "value" of a single PolicySet.
p13, table 1: column 2: I believe that because a PolicySet can contain
multiple Policies and multiple PolicySets that the title of this column
would be better as "PolicySet/Policy Values", instead of the current
"Policy Values" (note: I have capped all words in the column headers,
but that is just a suggestion as well, however if only the element names
are capped, then that I think is ok, too)
p15: I suggest adding a "Table 6a" or "Table 7" that will show the
evaluation of a single "match element". In particular, I think that the
last paragraph before section 3, starting with "Finally, the evaluation
of a match element ..." describes what should be in this proposed
table.

Yes, you are absolutely right. We are going to address these issues in our
technical report.

p16, table 7: My sense is that this should begin as something like:
 PDPpolicySet ::= Palg;PolicySet    (single top level PolicySet)
 PolicySet ::= { Palg;PolicySet | Ralg:Policy }  (multiple PolicySets and
Policies)
I am not sure of the syntax of the above lines, which will come out
in some subsequent comments below.
p16, table 7: I do not understand the "double constructs" that appear at
the end of the Policies line: " | Policies Policies " and at
the end of the Rules line: " | Rules Rules "
Please explain, maybe I missed it in the text.
p16, table 7: the second line of the Policies defn has angle brackets
surrounding the "policy". I assume this indicates there is only "one"
construct allowed, as opposed to the curly brackets in the prev line
which I assume means repeated constructs are allowed (in the PolicySet).
A general suggestion on p15, sec 3.1 1st para: please explain here, in
addition
to the square brackets, all the other constructs that are used in the EBNF
syntax you are using. BNF is notorious for having as many dialects as there
are authors who use it, so in the absence of a solid std, authors should
probably, imo, say what they are using in enough detail incl a ref to a BNF
baseline that will enable a reader not to have to deduce it all.

We see these issues related. We think that the difficulties in understanding
syntax of the policy language are due to an unfortunate notation: brackets
( . ), < . > and { . } are terminal symbols of our grammar (in fact,
they are used
as delimiters for rules, policies and policy sets, respectively), while
brackets [ . ] are used as EBNF meta-notation to indicate optional
items (that is,
everything that is set within the square brackets may be present just once, or
not at all). This might be confusing (the examples in Sec. 3.1 may
help to clarify).
We will add some remarks in the technical report on the dialect of the EBNF
that we used, in order to clarify.

Instead, regarding the "double constructs", it simply indicates the
juxtaposition of two terms. For example, the production
Rules   ::=   (Effect; ...)   |   Rules  Rules
means that within the block "rules:{...}" of a policy there can be
more terms of the form (Effect; ...) juxtaposed.

p18: preliminary comment on the general match element as opposed to
the XACML 2.0 category-specific match elements: XACML 3.0 has taken
this approach, and, imo, unfortunately, while cleaning up the syntax,
has muddied up the semantics. In particular, the category-specific matches
had the benefit of maintaining all the matches that were grouped together
as automatically referring to the corresponding category in the request.
In 3.0 by generalizing the match elements, there was a possibly inadvertent
side effect of no longer having this correspondence, which effectively means
that any group of attrs in the policy can refer to anything in the request.
I think the same issue may be introduced here. There are ways to address
this, but they have been deferred for the present, however, I advise being
careful not to introduce this issue in a 2.0 context.

As you correctly notice, in order to obtain a simpler syntax and
a manageable semantics, we have generalized the match elements by
avoiding the explicit use of categories in the syntax of targets.
This is justified by the fact that the evaluation of the information
in different categories is performed in the same way. However,
to adhere to the XACML 2.0 specification, and hence
to avoid the side effect that you mentioned above
(i.e. matches can refer to anything in the request), it is required
a disciplined use of names and the three logical operators we use
for expressing targets (as shown in Section 3.1). In our examples,
we use structured names (using the dot-notation) to express the
logical categories, e.g. subject.xspa_subject-id may represents
the XSPA Subject ID value (i.e. it refers to the Subject category).
What is your opinion on that?

One additional piece of info is that the OpenAz project has an "abbreviated"
XACML
syntax that I believe can fit into the semantics you have proposed:
http://openliberty.org/wiki/index.php/OpenAz_Main_Page

One would need to go the code repository that is linked from the wiki to get
to
the details, but I expect that once I have the syntax in the paper clarified
that
we will be able to do the mapping.

This would be really interesting. Unfortunately, I wasn't able to
access the grammar defined.
Can you please point me at the docs or to the code? We would be really
glad to start working
on that.

Best Regards,

      Massimiliano (also on behalf of the other authors)