Re: [xacml] Attribute Assertions in request context

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

Hi Paul,

I don't see this as an "either x or y" situation. As you suggested I went back to Greg's
presentation to frame my "issue", and to put it in the context of the subsequent
discussions.

In Greg's presentation slides 16, 18 he had 2 approaches identified as his favorites:

• slide 16: approach 2: short term favorite: "Conditions Implicit in Globally-Defined Attributes",
  where the "condition is evaluated by the Issuer, and the result assigned to a G-D Attribute".
  
• slide 18: approach 4: long term favorite: "Conditions in Request Context",
  where the "condition is a simple or complex expression of G-D Attributes and it is this
  expression that is presumably represented as a complex (or simple) Attribute structure,
  where the Issuer provides the expression natively to the PEP, which presumably translates
  the expression to a XACML Attribute, with Issuer assigned as the provider of the original
  expression, and the content being an XML representation of this expression, and the PDP
  is expected somehow to be extended to process this XML.

I coined the term "simple" for the first approach, because the all the Policy needs to do is use
the G-D Attribute in a simple expression, such as a boolean test of the G-D Attribute value.

I coined the term "complex" for the second approach, because in that case the Policy appeared
to be processing a complex condition such as the tree on slide 14.

However, based on the bullets above, the approaches might be called "Implicit Conditions"
and "Explicit Conditions", where

• implicit implies the condition is evaluated prior to being passed to the PDP and it is
  the result that is passed in a named G-D Attribute in the RequestContext.
• explicit implies the condition, itself, in xml form, is "explicitly" passed in the RequestContext
  and must be processed by the PDP.

One further point I'd like to add:

Rather then creating a new term such as "G-D Attribute", I think the fact that it would
be a normal XACML Attribute, with a normal XACML AttributeId, where the
AttributeId is defined to be a URI, kind of already captures the notion of a globally
defined attribute, since a URI should implicitly be a globally usable identifier, and all
that's really necessary is that these URIs be published by the providers and that
Policy uses the URIs as AttributeIds.

I also think that since the "Globally Defined Attribute" approach can be implemented using
existing XACML 2.0 and 3.0 technology, that what I am suggesting is that this approach
be explored more fully as to usability, etc. Personally, I think in theory it can be used to
solve the technical problem, but there is the potential issue that if providers do not provide
"condition evaluation" then things get a little less clean as the PEP would then need to do
that and possibly the chain to the original Issuer would start to erode.

But, ultimately, I think that it is enterprises that are in the business of defining policy in
terms of attributes will be looking for a wide range of solutions depending on the
specifics of the use case to which the policy is being applied.

    Thanks,
    Rich


Tyson, Paul H wrote:

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

I too appreciate Rich’s summary and Greg’s latest considerations.

 

I object to the characterizations “simple” and “complex”, and propose instead to label them more accurately.

 

The “simple” solution is an ad hoc workaround for which no benefits of standardization have been given.

 

The “complex” solution is a natural and logical extension to the core XACML model of policy evaluation against a request context.  I have proposed an (almost) completely backwards-compatible superset that could be standardized as an optional profile without drastically affecting existing implementations.

 

Finally, I don’t know why the TC has choose one or the other.  Someone should put forth a concrete proposal for working around the deficit of attribute assertions in the request context (a.k.a the “simple” solution), and we can debate a) whether it merits standardization; and b) whether it is the best solution possible, and if not how to improve it.

 

Regards,

--Paul

 

From: Gregory Neven [mailto:nev@zurich.ibm.com]
Sent: Tuesday, February 01, 2011 09:38
To: Rich.Levinson
Cc: Tyson, Paul H; Franz-Stefan Preiss; XACML
Subject: Re: [xacml] Attribute Assertions in request context

 

Hi Rich and Paul,

Thanks, Rich, for the good overview of the status of this discussion. I agree with everything you wrote, in particular with the fact that the recent discussions have deviated from the "simple" solution (with a translation table between local attributeIDs and predicates over global attributeIDs) to the "complex" solution (with attribute predicates all the way down into the PDP).

As much as I like the discussions with Paul on the complex solution, I think there are a couple of challenges left to make it work, so we may want to re-consider the options we have on the table:

Option 1: Simple solution

As described on slide 10 of http://www.oasis-open.org/committees/document.php?document_id=39960. Either the PEP or the ContextHandler maintains a translation table between locally meaningful boolean attributeIDs and predicates over globally meaningful attributeIDs. The policy and request context are specified in terms of the local attributes, the communication to the outside world (user or IDP) contains predicates over global attributes.

The main advantage of this solution is that hardly any changes are needed to XACML at all. Mainly, one would have to specify where and how the mapping between local and predicates over global attributes is done, similarly to the mapping between saml:Attribute and xacml-context:Attribute in the SAML profile of XACML. Another advantage is that arbitrarily complex predicates can be supported without problem. More details are in one of my earlier posts (http://lists.oasis-open.org/archives/xacml/201011/msg00025.html).

Option 2: Complex solution with simple predicates

This was the last solution that Paul suggested (http://lists.oasis-open.org/archives/xacml/201101/msg00030.html), after we pointed out some problems with his approach for nested predicates. One could restrict the type of predicates to "attribute operator value", which would cover the "age > 18" and "birthday < 1993/01/01" examples. Probably one could also include "attribute operator attribute" predicates, which would cover the "waist > inseam" example from Paul's Short Fat Man fun run (http://wiki.oasis-open.org/xacml/AttributeAssertionsInRequestContext).

As Franz-Stefan pointed out (http://lists.oasis-open.org/archives/xacml/201101/msg00021.html), the proposed approach gets into trouble with nested predicates, e.g., "birthdate + 18 years < today". Other use cases from my slides that would not be covered are "first 5 characters of phonenr are +4144" or "domain of email address is ibm.com".

But regardless of whether the simple predicates cover the most important use cases, there are a couple of problems left to be solved still even if we restrict to simple predicates. Namely:

• For each function that we want to support, we would have to specify by which predicates it can be satisfied, as Paul did in Prolog notation for the greater-than function (http://wiki.oasis-open.org/xacml/AttributeAssertionsInRequestContext). Depending on how "intelligent" we want the matching to be, this may get quite complex. For example, there may be dependencies between different functions, as Paul correctly pointed out in his Prolog example between the >= and > operators. Solving this problem may take some more research, or at least literature study. We don't have the knowledge in-house to solve this on the short term, but will check again with colleagues.
• Reporting "missing predicates" to the user/IDP remains an open question. When the PDP encounters an attribute that is not in the context, it will only report the AttributeID of the missing attribute, not the predicate surrounding it. The user/IDP therefore can't find out which predicate it has to prove.

Option 3: Complex solution with complex predicates

This solution has the same problems as option 2, but in an amplified way. If checking whether predicate A implies predicate B was already non-trivial for simple predicates, it is even more so for arbitrarily nested predicates. Also, when reporting missing predicates, there is the additional challenge of deciding which "level" of the predicate to report as missing, as explained on slide 14 of http://www.oasis-open.org/committees/document.php?document_id=39960.

Best regards,
Greg



On 1/29/2011 08:30, Rich.Levinson wrote:

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:

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:

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