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


Rich, the topic of credentials belongs in a different thread

 

The starting point and motivation for Attribute Assertions was the presentation (also from Greg) referenced from this post:

http://lists.oasis-open.org/archives/xacml/201010/msg00010.html

 

My proposal for Attribute Assertions just defines a useful superset of XACML that would not affect legacy implementations.

 

Regards,

--Paul

 

From: Rich.Levinson [mailto:rich.levinson@oracle.com]
Sent: Wednesday, January 26, 2011 19:56
To: Franz-Stefan Preiss
Cc: XACML
Subject: Re: [xacml] Attribute Assertions in request context

 

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:

  1. Define a new SubjectCategory (see XACML 3.0 setion B.2), for example:
      "urn:oasis:names:tc:xacml:3.0:subject-category:credential"
  2. 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"
  3. Then for a given credential type, the "issuer" can send in an Attributes
    collection with Attribute elements containing attributes appropriate to
    that credential-type.
  4. Policy statements can use AttributeDesignators to find these attributes
    and apply appropriate constraints.
  5. 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:


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]