Re: [xacml] Attribute Assertions in request context

["Rich.Levinson" <rich.levinson@oracle.com>]

Hi Greg and Paul,

I understand your comments that the context for the current discussion is the
original slide set which was uploaded to the repository on this email:
  http://lists.oasis-open.org/archives/xacml/201011/msg00000.html
which I did on request from Bill as the original email from Bill pointed
to a private location. In any event the slides are here:
  http://www.oasis-open.org/committees/document.php?document_id=39960

The reason I went to the paper by Greg's group:
  http://www.w3.org/2009/policy-ws/papers/Neven.pdf
was that I was not able to obtain sufficient context from the slides alone
to understand the motivation for the current discussions.

I have gone over the slides again in the context of the paper and think that
I now have a better understanding of the problem being solved. My
understanding now is that the key concept is:

There is an identity provider (idp) that is supplying information to the PEP
about the user in some non-xacml form, which can include "attribute
predicates", where these predicates are actually "assertions" about
the user such as "age > 18" or "birthday < 2010/10/21". Some of these
are captured on slide 7 of Greg's presentation.

There are a couple of aspects of the problem that are discussed in the
slide set:

• one aspect is how the PEP "gets" the info from the idp, and what
  is being considered is that it is a SAML idp, and that some kind
  of syntax can be developed, as indicated on slide 8. However,
  this is outside the scope of XACML, except for the fact that
  the information will be available in some specific form.
• the second aspect is how the PEP translates the information
  received from the idp and puts it in a XACML request - slide 9.
• finally, there are two proposed approaches for dealing with the
  second aspect of translating the predicates to XACML:
• a "simple solution" slide 10, where the result of predicate
  evaluation is a boolean captured in a named attribute
  (ex.AttributeId = "uri:local:overage" with AttributeValue=true)
  In some earlier discussion, Greg and I appeared to be in
  agreement on this:
  http://lists.oasis-open.org/archives/xacml/201011/msg00024.html
• a "more complex solution", slide 11, which can include complex
  expressions like the parse tree in slide 14.
  

What seems to have happened, imo, is that recent discussion has focused
almost exclusively on developing technology to address the "more complex
solution", while the "simple solution" has been more or less ignored. At least
this explains to me why I was having trouble understanding the context of
the current discussions.

That being said, I have looked back at what triggered the current thread, and
the thread that Greg and I agreed on, and some other threads as well that
may not have yet been fully addressed.

In particular, the following discussion is copied from the November 18 minutes:
  http://lists.oasis-open.org/archives/xacml/201011/msg00015.html

"Primelife proposal Next Steps
  Hal suggested that it would be very difficult to creature a convention
  that would address attributes which would represent predicates.
  Gregory asked if possibly uri prefixes might denote these attributes?

  Gregory offered that a possible update to the SAML/XACML Profile
  mapping between predicates and local attributes

  Rich agreed that a Profile is the way to address this given the
  initial discussions, but that much more information is needed.

  Hal suggested that the Profile may possibly be aimed at the Context
  Handler. 

  Paul offered that whatever solution the TC comes up upon be a long
  range solution.

  Gregory suggested that the "complex solution" be pursued whereby the
  Context Handler is predicate aware and can perform ancillary
  processing and match "qualified" with "certified" condition derived
  results. 

  Hal suggested that it may be very difficult to achieve since it is
  effectively Policy matching (heretofore intentionally avoided by the TC
  due to complexity). Of the 3 scenarios presented by Gregory in his
  first presentation, the first appears to be directly addressable and
  as does the second (possibly using using a Convention by using an
  annotation). The third case may be too complex.

  Paul suggested that we should explore the more complex cases before
  dismissing them and offered to explore the topic.

  Gregory volunteered to post a note to the list to initiate
  conversation online. "
  

Subsequent to that meeting Greg posted a proposed approach to the simple solution
that I do not think has been discussed:
  http://lists.oasis-open.org/archives/xacml/201011/msg00025.html

There are a number of issues that Greg raised at the end of that proposal that
probably deserve some attention.

One reason I think it is important to pursue this approach is that, imo, the
definition of boolean attributes to represent the results of predicate evaluation
may, in fact, be the better approach, as opposed to pushing the evaluation
of the predicates into the PDP. A couple reasons I think this:

• it is desirable to define common vocabularies for attributes that the
  policies will use and that the PEPs will supply as parameters to
  the xacml request context.
• chances are that even if the predicates are pushed into the PDP,
  that the best way to process them, may be to define new functionality,
  which effectively pushes the solution outside the base set of core
  and profiles into an "extension".
• these "extensions" already should be able to be implemented using
  the "attribute finder" approach, where it is the finder itself that takes
  on the responsibility of evaluating the predicate and returning
  a result to the PDP. This started to be discussed in the emails
  ref'd above, but needs more work.

Also, as indicated in my previous email, I recognize the need for
"advertising" the policy so users will know what needs to be provided,
and I want to mention again, that the unfinished spec WS-XACML
may be an excellent starting point for covering that part of the overall
problem, which I think is further useful context in that it shows how
the AttributeId, one way or another, needs to be pushed out by the
policy in order that the PEP may have the info it needs to inform
users what they need to provide to access specific resources.

    Thanks,
    Rich

Gregory Neven wrote:

4D418B4D.7030508@zurich.ibm.com" type="cite"> Hi Rich,

Paul is right: the credential-based access control from the paper you mentioned is a different discussion that is quite orthogonal to supporting attribute predicates. I'd be happy to have that discussion too, but probably the ideas would be even more invasive in the XACML language and processing model.

Best,
Greg

On 1/27/2011 14:59, Tyson, Paul H wrote:

3898C40CCD069D4F91FCD69C9EFBF09605C6F8C9@txamashur004.ent.textron.com" type="cite">

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