OASIS eXtensible Access Control Markup Language (XACML) TC

This is a follow-up to my original post at [1], and Greg's response [2].

No syntax change in the request language is required.  

This is a response to Paul's message at [1], which was a follow-up to [2] and [3]. That's actually a quite interesting idea, Paul, to create a new datatype to embed a predicate as an AttributeValue, we didn't think of that. So would you envisage that the included <Apply> element contains a predicate that only involves the attribute specified in the enclosing <Attribute> element, or that it could involve other attributes as well? In the latter case, it would actually offer the level of expressivity that we need to express, e.g., graduationDate < birthdate + 18Y. I imagine though that using the same AttributeId=" http://www.example.org/attributes/age" ; with DataType=".../assertion" in the <Attribute> and <AttributeValue> elements and with DataType="...#integer" in an enclosed <AttributeDesignator> can cause problems. Your suggestion inspired us for the following approach. How about we specify a profile that defines a new DataType " http://www.example.org/attpredicates#predicate" ;, a new AttributeId " http://www.example.org/attpredicates#the-certified-predicate" ;, and a new FunctionId " http://www.example.org/attpredicates#implies" ;. The DataType "...#predicate" is a complex type containing a single <xacml:Apply> element (which could actually contain the conjunction of multiple predicates by means of the "...:function:and" function). The XACML request context can specify a value for the attribute "...#the-certified-predicate", e.g., <Attributes Category="...:access-subject"> <Attribute IncludeInResult="false" AttributeId="...#the-certified-predicate"> <AttributeValue DataType="...#predicate"> <Apply FunctionId="...:integer-greater-than-or-equal"> <AttributeDesignator DataType="...#integer" AttributeId=" http://www.example.org/attributes/age" ;> <AttributeValue DataType="...#integer">30</AttributeValue> </Apply> </AttributeValue> </Attribute> </Attributes> In the policy, the policy author must explicitly specify that a certain condition can be satisfied by a matching certified predicate, rather than having to provide full attribute values, by enclosing it in an <Apply> with the "...#implies" function, e.g., <Condition> <Apply FunctionId="...#implies"> <AttributeDesignator DataType="...#predicate" AttributeId="...#the-certified-predicate"/> <AttributeValue DataType="...#predicate"> <Apply FunctionId="...:integer-greater-than-or-equal"> <AttributeDesignator DataType="...#integer" AttributeId=" http://www.example.org/attributes/age" ;> <AttributeValue DataType="...#integer">30</AttributeValue> </Apply> </AttributeValue> </Apply> </Condition> The entire logic of checking whether the certified predicate implies the condition in the policy can then be contained in the implementation of the "...#implies" function, which could be very simple by checking string equality modulo XML whitespace, or which could be more intelligent by calling out to Prolog as you suggested. We can discuss during the upcoming call. Best regards, Greg [1] http://lists.oasis-open.org/archives/xacml/201011/msg00033.html [2] http://lists.oasis-open.org/archives/xacml/201010/msg00012.html [3] http://lists.oasis-open.org/archives/xacml/201011/msg00001.html > <Attributes > Category="...:access-subject"> > <Attribute IncludeInResult="false" > AttributeId=" http://www.example.org/attributes/age" ;> > <AttributeValue > DataType=" http://www.example.org/datatype/assertion" ;> > <Apply > FunctionId="...:integer-greater-than-or-equal"> > <AttributeDesignator DataType="...#integer" > AttributeId=" http://www.example.org/attributes/age" ;> > <AttributeValue > DataType="...#integer">30</AttributeValue> > </Apply> > </AttributeValue> > </Attribute> > </Attributes> > > The syntax is ungainly, and not what you would design anew. But it has > the advantage of using familiar terms and syntax. > > I believe the semantics and expected policy evaluation behavior could be > specified very easily. First it would be necessary to define a xacml > datatype id for "assertion", which would allow (and limit) the content > of<AttributeValue> to the XACML expression language. > > The next problem is how to specify the evaluation of a policy against > this type of request context. Prolog provides a good model for this. > Here's a prolog rule that defines when the condition is true: > > gte(R,A) :- R =>=(X,Y), A =>=(X,Z),>=(Z,Y). > > This defines a predicate, 'gte' (greater-than-or-equal) which is true > iff the first argument (the Rule) is a '>=' expression with two > operands, the second argument (Assertion) is a '>=' expression with the > same first operand as the first expression, and the 2nd operand of A is > greater than or equal to the 2nd operand of R. > > So, 'gte(>=(X,21),>=(X,30))' returns "Yes" in a prolog system, but > 'gte(>=(X,21),>=(X,20))' returns "No". > > This can be made more general by adding clauses to the body of the rule: > > gte(R,A) :- R =>=(X,Y), A =>=(X,Z),>=(Z,Y); > R =>=(X,Y), integer(A),>=(A,Y); > R =>=(X,Y), A =>(X,Z),>=(Z,Y). > > The 2nd clause allows the Assertion to be simply an integer (the age). > (This corresponds to having a bare AttributeValue in the request context > instead of an attribute assertion.) The 3rd clause allows the Assertion > to be a strictly greater-than comparison. If any of the clauses are > true, the predicate returns "Yes". > > My point is that Prolog or something like it could be used to specify > the policy evaluation behavior for attribute assertions. I demonstrated > here how it can be done for numerical comparisons. This could be easily > extended to date comparisons. I haven't looked at string comparisons, > but that should be straight-forward. Regular expressions will be more > difficult, but we might be able to define a useful subset of regular > expression comparisons. (But are there really any compelling use cases > for comparing a regular expression condition in a policy to a regular > expression attribute assertion?) > > Regards, > --Paul > > [1] http://lists.oasis-open.org/archives/xacml/201010/msg00012.html > [2] http://lists.oasis-open.org/archives/xacml/201011/msg00001.html > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > >

I proposed a way to meet the requirement without changing the request syntax, by using the fact that <AttributeValue> is an extension point. After thinking about it, this is probably an unnecessary constraint. We could extend the request syntax and remain backward-compatible by defining a new element, <AttributeAssertion>, and allowing a choice of AttributeValue AttributeAssertion in <Attribute>. The content model of AttributeAssertion would be an Apply element. If we back up and look for the root cause of this problem, it is simply that the request context does not admit any predicates other than equality. If we relax this constraint then standard XACML can meet many more use cases (including privacy protection). And I do not think the implementation burden is very great. It does of course introduce a greater range of indeterminate solutions, but this will have to be addressed with better policies. I don't see how this requires the policy writer to have any more knowledge of the potential request context than currently required (a concern expressed by Erik in [1])--in fact, if the policy rules are true expressions of business requirements there should be no change to existing policies. I do not favor Greg's suggestions. Although I initially proposed an "assertion" datatype, I think this is the wrong direction. It needs to be an element (AttributeAssertion), with a content model that provides a full predicate expression language (the xacml:Apply element). We could meet the need of "#the-certified-predicate" by defining a "this" construct to use in the context of Attribute/AttributeAssertion/Apply to refer to the AttributeId on the Attribute ancestor. Other AttributeDesignators would serve their normal purpose of referring to attributes in the request context. And the "#implies" function-id is not needed as a syntactic feature. Policy evaluation (as defined in section 7 of the spec) is all about deriving the truth-value of the logical implication represented by a policy set. Although abstractly, there's nothing wrong with including explicit logical implications within a rule, I don't see any need to add this as a standard function. I don't have time right now to work up a complete example, but will do so as time permits. Regards, --Paul [1] http://lists.oasis-open.org/archives/xacml/201101/msg00008.html >
Original Message----- > From: Gregory Neven [ mailto:nev@zurich.ibm.com ] > Sent: Thursday, January 13, 2011 11:38 > To: XACML > Cc: Paul Tyson > Subject: Re: [xacml] Attribute Assertions in request context > > This is a response to Paul's message at [1], which was a follow-up to > [2] and [3]. > > That's actually a quite interesting idea, Paul, to create a new > datatype > to embed a predicate as an AttributeValue, we didn't think of that. So > would you envisage that the included <Apply> element contains a > predicate that only involves the attribute specified in the enclosing > <Attribute> element, or that it could involve other attributes as well? > In the latter case, it would actually offer the level of expressivity > that we need to express, e.g., graduationDate < birthdate + 18Y. > > I imagine though that using the same > AttributeId=" http://www.example.org/attributes/age" ; with > DataType=".../assertion" in the <Attribute> and <AttributeValue> > elements and with DataType="...#integer" in an enclosed > <AttributeDesignator> can cause problems. > > Your suggestion inspired us for the following approach. How about we > specify a profile that defines a new DataType > " http://www.example.org/attpredicates#predicate" ;, a new AttributeId > " http://www.example.org/attpredicates#the-certified-predicate" ;, and a > new FunctionId " http://www.example.org/attpredicates#implies" ;. The > DataType "...#predicate" is a complex type containing a single > <xacml:Apply> element (which could actually contain the conjunction of > multiple predicates by means of the "...:function:and" function). The > XACML request context can specify a value for the attribute > "...#the-certified-predicate", e.g., > > <Attributes > Category="...:access-subject"> > <Attribute IncludeInResult="false" > AttributeId="...#the-certified-predicate"> > <AttributeValue > DataType="...#predicate"> > <Apply > FunctionId="...:integer-greater-than-or-equal"> > <AttributeDesignator DataType="...#integer" > AttributeId=" http://www.example.org/attributes/age" ;> > <AttributeValue > DataType="...#integer">30</AttributeValue> > </Apply> > </AttributeValue> > </Attribute> > </Attributes> > > In the policy, the policy author must explicitly specify that a certain > condition can be satisfied by a matching certified predicate, rather > than having to provide full attribute values, by enclosing it in an > <Apply> with the "...#implies" function, e.g., > > <Condition> > <Apply FunctionId="...#implies"> > <AttributeDesignator DataType="...#predicate" > AttributeId="...#the-certified-predicate"/> > <AttributeValue DataType="...#predicate"> > <Apply FunctionId="...:integer-greater-than-or-equal"> > <AttributeDesignator DataType="...#integer" > AttributeId=" http://www.example.org/attributes/age" ;> > <AttributeValue DataType="...#integer">30</AttributeValue> > </Apply> > </AttributeValue> > </Apply> > </Condition> > > The entire logic of checking whether the certified predicate implies > the > condition in the policy can then be contained in the implementation of > the "...#implies" function, which could be very simple by checking > string equality modulo XML whitespace, or which could be more > intelligent by calling out to Prolog as you suggested. > > We can discuss during the upcoming call. > > Best regards, > Greg > > [1] http://lists.oasis-open.org/archives/xacml/201011/msg00033.html > [2] http://lists.oasis-open.org/archives/xacml/201010/msg00012.html > [3] http://lists.oasis-open.org/archives/xacml/201011/msg00001.html > > > > > <Attributes > > Category="...:access-subject"> > > <Attribute IncludeInResult="false" > > AttributeId=" http://www.example.org/attributes/age" ;> > > <AttributeValue > > DataType=" http://www.example.org/datatype/assertion" ;> > > <Apply > > FunctionId="...:integer-greater-than-or-equal"> > > <AttributeDesignator DataType="...#integer" > > AttributeId=" http://www.example.org/attributes/age" ;> > > <AttributeValue > > DataType="...#integer">30</AttributeValue> > > </Apply> > > </AttributeValue> > > </Attribute> > > </Attributes> > > > > The syntax is ungainly, and not what you would design anew. But it > has > > the advantage of using familiar terms and syntax. > > > > I believe the semantics and expected policy evaluation behavior could > be > > specified very easily. First it would be necessary to define a xacml > > datatype id for "assertion", which would allow (and limit) the > content > > of<AttributeValue> to the XACML expression language. > > > > The next problem is how to specify the evaluation of a policy against > > this type of request context. Prolog provides a good model for this. > > Here's a prolog rule that defines when the condition is true: > > > > gte(R,A) :- R =>=(X,Y), A =>=(X,Z),>=(Z,Y). > > > > This defines a predicate, 'gte' (greater-than-or-equal) which is true > > iff the first argument (the Rule) is a '>=' expression with two > > operands, the second argument (Assertion) is a '>=' expression with > the > > same first operand as the first expression, and the 2nd operand of A > is > > greater than or equal to the 2nd operand of R. > > > > So, 'gte(>=(X,21),>=(X,30))' returns "Yes" in a prolog system, but > > 'gte(>=(X,21),>=(X,20))' returns "No". > > > > This can be made more general by adding clauses to the body of the > rule: > > > > gte(R,A) :- R =>=(X,Y), A =>=(X,Z),>=(Z,Y); > > R =>=(X,Y), integer(A),>=(A,Y); > > R =>=(X,Y), A =>(X,Z),>=(Z,Y). > > > > The 2nd clause allows the Assertion to be simply an integer (the > age). > > (This corresponds to having a bare AttributeValue in the request > context > > instead of an attribute assertion.) The 3rd clause allows the > Assertion > > to be a strictly greater-than comparison. If any of the clauses are > > true, the predicate returns "Yes". > > > > My point is that Prolog or something like it could be used to specify > > the policy evaluation behavior for attribute assertions. I > demonstrated > > here how it can be done for numerical comparisons. This could be > easily > > extended to date comparisons. I haven't looked at string > comparisons, > > but that should be straight-forward. Regular expressions will be > more > > difficult, but we might be able to define a useful subset of regular > > expression comparisons. (But are there really any compelling use > cases > > for comparing a regular expression condition in a policy to a regular > > expression attribute assertion?) > > > > Regards, > > --Paul > > > > [1] http://lists.oasis-open.org/archives/xacml/201010/msg00012.html > > [2] http://lists.oasis-open.org/archives/xacml/201011/msg00001.html > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. Follow this link to all your TCs in OASIS at: > > https://www.oasis- > open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php