xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xacml] Attribute Assertions in request context
- From: Franz-Stefan Preiss <FRP@zurich.ibm.com>
- To: XACML <xacml@lists.oasis-open.org>
- Date: Wed, 26 Jan 2011 11:05:49 +0100
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]