Hi Franz-Stefan, Greg, and Paul,
I have been trying to understand what this discussion is substantively
about since
Greg's presentations in October.
The most recent discussion on Attribute Assertions, while being fairly
concrete,
does not seem to me on the surface to provide motivation behind the
proposals,
leaving me wondering what the need is to what appears to be fairly
drastic
modifications to the current XACML request/response paradigm by
including
Policy language, itself, in the form of predicates within the
Attributes structure.
Also, I recognize that there is a strong desire to address a problem
with this
technology, so I went back to the original presentation materials to
re-familiarize
myself with the problem being solved. The original presentation
material is
referenced here:
http://lists.oasis-open.org/archives/xacml/201011/msg00000.html
which is an email I sent on Greg's behalf before he had access to the
OASIS
email in the necessary manner to send mail to the list.
In any event, since I had already reviewed the presentation, I decided
to look
at the reference document, which is a paper Greg and Franz-Stefan and
their
colleagues have published and made available here:
http://www.w3.org/2009/policy-ws/papers/Neven.pdf
At least for me, I think I understand better now, based on that paper
what is
trying to be achieved here.
Let me see if I can characterize the problem based on the paper in
another
proposed solution type:
According to the paper:
"Credentials must be the basic unit for reasoning about
access control. Users do not have standalone
attributes, but rather own credentials that contain sets of attributes.
Credentials must
be of a certain credential type that determines the attributes
contained in the credential. The
policy specifies the credential type that must be used to satisfy the
policy. For example, when
a government issues birth certificates as well as ID cards, both of
which contain the owner’s last
name, then the service provider can specify in his policy that he wants
the last name as stated on
an ID card, not on a birth certificate."
To me, the key takeaway here is:
"Users ... own credentials that contain sets of attributes."
i.e. it appears that a "credential" can be modeled as a "collection of
attributes".
Therefore, I suggest the following approach to address the problem:
- Define a new SubjectCategory (see XACML 3.0 setion B.2), for
example:
"urn:oasis:names:tc:xacml:3.0:subject-category:credential"
- Define a couple of AttributeIds, such as:
"urn:oasis:namee:tc:xacml:3.0:subject:credential-type"
"urn:oasis:namee:tc:xacml:3.0:subject:credential-id"
- Then for a given credential type, the "issuer" can send in an
Attributes
collection with Attribute elements containing attributes appropriate to
that credential-type.
- Policy statements can use AttributeDesignators to find these
attributes
and apply appropriate constraints.
- Also, services can advertise the credential requirements,
possibly along
the lines of the "Web Services Profile of XACML":
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml#CURRENT
which is an unfinished spec, but well advanced and may be exactly what
is needed to address one of the main objectives in the paper as stated
in
the abstract:
"paradigm shift towards openness and user-centricity where service
providers
communicate to the users what information they need to provide to
gain access
to a given resource."
Comments, suggestions?
Thanks,
Rich
Franz-Stefan Preiss wrote:
OF4E7CC700.47AF7CDC-ONC1257823.005828C9-C1257824.003775D5@ch.ibm.com"
type="cite">
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
------------------------------------------------
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
|