From: Franz-Stefan Preiss [mailto:FRP@zurich.ibm.com]
Sent: Wednesday, January 26, 2011 04:06
To: XACML
Subject: Re: [xacml] Attribute Assertions in request context
Dear Paul, All,
>> I summarized my thoughts on this subject in a wiki page,
>> http://wiki.oasis-open.org/xacml/AttributeAssertionsInRequestContext.
thanks a lot for the effort of doing so and for choosing such an entertaining example theme :-)
The attribute assertion syntax that you propose seems well suited for the problem at hand. Clearly, this would involve changing the XACML language, but let's assume we don't have constraints in that respect.
The concept of polymorphic XACML comparison functions is a certainly interesting approach for evaluating policies against attribute assertions. However, Greg and myself have the impression that the polymorphic functions do not work for certain policy structures.
We understand that the use of polymorphic functions is intended to allow reusing the existing XACML policy evaluation algorithm, which seems to perfectly work for 'non-nested' predicates, but not for 'nested' ones. Consider the following example that expresses your 'age'-example in terms of a nested policy involving a 'dateOfBirth' attribute:
--------------------------------------------
Policy:
--------------------------------------------
...
<Condition>
<Apply FunctionId="...:assertion-evaluation:date-less-than-or-equal">
<Apply FunctionId="...:date-add-yearMonthDuration">
<AttributeDesignator DataType="...#date" AttributeId="http://example.org/dateOfBirth">
<AttributeValue DataType="...#yearMonthDuration">P30Y</AttributeValue>
</Apply>
<AttributeDesignator Category="...:environment" DataType="...#date" AttributeId="...:current-date"/>
</Apply>
</Condition>
...
--------------------------------------------
Request:
--------------------------------------------
<Attributes Category="...:access-subject">
<Attribute AttributeId="http://example.org/dateOfBirth">
<AttributeAssertion>
<Apply FunctionId="...:date-less-than-or-equal">
<Apply FunctionId="...:date-add-yearMonthDuration">
<AttributeDesignator DataType="...#date" AttributeId="...:this-attribute">
<AttributeValue DataType="...#yearMonthDuration">P30Y</AttributeValue>
</Apply>
<AttributeValue DataType="...#date">2011/01/25</AttributeValue>
</Apply>
</AttributeAssertion>
</Attribute>
</Attributes>
--------------------------------------------
In this example the policy requires a requester to be older than 30 years (by means of the date of birth).
As the requestor asserts exactly this predicate, the access should intuitively be granted.
(Note: it's unclear whether the predicate in the request shall contain the environment attribute '...:current-date' rather than a concrete date, 2011/01/25 in this case).
However, the default XACML evaluation algorithm would fail in this case as the '...assertion-evaluation:date-less-than-or-equal'-<Apply> would consider the whole 'dateOfBirth'-<AttributeAssertion> of the request when encountering the 'dateOfBirth'-<AttributeDesignator> in the policy.
To make this example succeed, XACML's default way of evaluating functions would have to be extended.
In particular, in the example this extension would have to match the content of the <Condition> "as a whole" (modulo environment attribute substitution, etc.) against the content of the <AttributeAssertion>.
In general, in addition to the standard evaluation functionality the extension would have to allow boolean <Apply> elements also to evaluate to true when a corresponding attribute assertion exists in the request., i.e., when an attribute assertion is provided that "implies" the predicate expressed with the <Apply> element. While such implication test could simply be implemented as equality test, also more sophisticated and complicated implication tests based on logics are conceivable here.
Another general open problem is how a requester learns what predicate she actually has to provide in the request, i.e. on what basis she shall create the attribute assertions in the request.
Also, an open question is which attribute would contain the attribute assertion in cases where the assertion involves multiple attributes (cf. the Short Fat Man fun run example), i.e., which one is chosen as the '...:this-attribute'.
>> I implemented a minimal policy evaluator [...] I will share it with the group if anyone is interested.
Please do so, I would be curious on how it behaves for nested policies.
Best Regards,
Franz-Stefan Preiss
------------------------------------------------
Franz-Stefan Preiss
IBM Research Zurich
Säumerstrasse 4, CH-8803 Rüschlikon, Switzerland
+41 44 724 8401
frp@zurich.ibm.com
------------------------------------------------
From: | Paul Tyson <phtyson@sbcglobal.net> |
To: | XACML <xacml@lists.oasis-open.org> |
Date: | 01/24/2011 03:46 AM |
Subject: | [xacml] Attribute Assertions in request context |
I summarized my thoughts on this subject in a wiki page,
http://wiki.oasis-open.org/xacml/AttributeAssertionsInRequestContext.
I implemented a minimal policy evaluator in XSLT to prove the concept of
polymorphic comparison functions to evaluate either attribute values or
attribute predicates in the request context. When it is a little
further along I will share it with the group if anyone is interested.
Although this introduces a bit more complexity, and a lot more room for
indeterminate policy evaluation, I think it would be useful extension to
XACML.
Regards,
--Paul
---------------------------------------------------------------------
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