OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Attribute Assertions in request context


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.  <AttributeValue>
is designed as an extension point, so it allows attributes and element
content from any namespace.  You could use your own assertion language,
or you could use the XACML expression language.  The following assertion
of "age is greater than 30" is synactically valid XACML 3.0, but the
content of the outer <AttributeValue> element is semantically
unspecified:

  <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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]