[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-users] Contribution for the XACML Reference list
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: where I have purposely left the combining Palgs and Ralgs and the EffectsPDPpolicies ::= {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 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: I think you will find that the syntactic structure is basically the same, whichPolicy (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 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:
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) |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]