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: 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
>
>
>
>



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