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 XACML request

Dear Rich,

The scenario described is exactly what we had in mind for the simple solution. We are currently having a couple more internal discussions, but will post the promised details on the open issues tomorrow.

You already touched on the main open issue, however:  it actually isn't quite clear to me to what extent the communication format for the "callout to the ContextHandler" for missing attributes is standardized, and if it is standardized, whether the format needs to be changed to support our use case.

Best regards,

4CE9D913.9070308@oracle.com" type="cite"> Hi Greg,

I am not sure if you got the email issues straightened out, but in order to
help move the thread along, I'll just include your direct email address.

I went over your slide presentation again, and I am trying, in particular,
to understand the xacml part of the issue as opposed to the saml part.

On slide 17, you indicate a preference short term for approach 2, which
I think sounds similar to the approach I would also recommend.

You characterize it as:
  • Policy in terms of dedicated, locally defined boolean attributes.
  • PIP or PEP knows mapping to conditions over globally defined attributes
    e.g., urn:mypolicy:underage -> (urn:unitednations:birthdate <= 1992/09/10)
  • Values of local attributes passed in request context
  • Missing local attribute -> request corresponding condition over global attrs
The way I look at situations like this, where information is need from an outside
provider, is to define an attribute in the Policy that is known not to be included
in the RequestContext, and has MustBePresent set, which will force the Policy
to raise an Indeterminate condition, which can either be sent back to the PEP
as MissingAttribute, or be intercepted during evaluation with a callout to the
ContextHandler as is done in the SunXacml reference implementation.

In the case at hand, I would have a condition that says:
  <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:boolean-equal">
    <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:boolean-one-and-only">
            Issuer="trusted-authority" />
    <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#boolean">true</AttributeValue>
I think the above is correct, but, in any event, what it is attempting to say is
For the Condition to be true:
  Look for an Attribute with AttributeId="urn:mypolicy:underage"
  And the value of this Attribute must be true (which I assume means the user is not underage)
In general, this attribute would not be found in the RequestContext, so a callback would
be initiated to try to find it. Given the name of the Issuer (="trusted-authority") the attr finder
would know where to go with the request, which would be something like:
Request attribute "global:underage" for user="xxx",
which would return either true or false for user "xxx",
which the attribute finder would return to the ContextHandler and policy evaluation,
which could then be compared to the required value of "true".
So, my question is: is this along the lines that you were thinking with Approach 2, and
if so, then what more is needed, as I think this approach can be quite flexible for addressing
this type of problem.


Rich.Levinson wrote:
4CD223A9.8040201@oracle.com" type="cite">Hi All,
I am posting this message on behalf of Greg Neven, as he has been experiencing some
difficulty getting properly registered to post email to XACML TC.
This message is relevant to the ongoing discussions from Greg's pres at last meeting,
which will continue as subject of discussion tomorrow.

-------- Original Message --------
Subject: Re: [xacml] Attribute Assertions in XACML request
Date: Fri, 29 Oct 2010 18:50:58 +0200
From: Gregory Neven <nev@zurich.ibm.com>
Organization: IBM Research - Zurich
To: xacml <xacml@lists.oasis-open.org>
CC: Paul H Tyson <PTyson@bellhelicopter.textron.com>, Franz-Stefan Preiss <FRP@zurich.ibm.com>

Dear Paul,

Very sorry about the delay in answering. I thought I had subscribed to 
the list, but must have done something wrong when signing up. Thanks to 
David for pointing out your post to me.

Just to make sure: you are talking about the XACML request context 
schema, and not SAML, right?

Embedding the predicate inside the Attribute element is indeed an 
interesting option for simple predicates of the form <attribute> 
<operator> <constant>, such as the birthday example that you mentioned. 
It would be harder though to express more complex predicates where 
operations have to be performed on the attribute itself (e.g., first 5 
characters of phone number are +4144) or where multiple attributes occur 
in a single predicate (e.g., graduationdate - birthdate < 18Y).

I also agree that no changes to the policy language itself would be 
required, but you would have to break open the schema of the XACML 
request context, right? Wouldn't that already prevent these extensions 
from being defined in a profile?  Because that was what I was trying to 
avoid in my "simple solution". But I definitely agree that multiple 
interesting issues come up in the "more challenging solution" that I 
sketched: how to communicate asserted predicates to the PDP, how to 
evaluate a policy against a set of asserted predicates, and also how to 
determine and communicate "missing predicates".

Best regards,

> -------- Original Message --------
> Subject: [xacml] Attribute Assertions in XACML request
> Date: Fri, 22 Oct 2010 08:15:57 -0500
> From: Tyson, Paul H <PTyson@bellhelicopter.textron.com>
> To: xacml <xacml@lists.oasis-open.org>
> Regarding Gregory Neven's proposal for attribute conditions in the
> request context:
> Greg's approach to put the full <Condition> element syntax in a SAML
> assertion would work.  But a simple change to the <Attribute> element
> structure in the request would also work.
> <Request>
> ...
> <Attribute AttributeId="example:bday" DataType="date-time">
> <AttributeAssertion
> FunctionId="...date-less-than">1990-10-01</AttributeAssertion>
> </Attribute>
> ...
> </Request>
> We allow <AttributeAssertion> in place of <AttributeValue>, and move
> DataType to the parent element.  We re-use the function identifiers
> already defined in XACML.
> <AttributeValue> is actually a degenerate case of attribute assertion,
> which only allows equality, or name-value pairs. <AttributeAssertion>
> generalizes this to allow other predicates besides equality.
> <AttributeAssertion FunctionId="...equals"> would be the semantic
> equivalent of <AttributeValue> for each datatype.
> In keeping with the bag-of-attribute-values paradigm for the request
> context, we would probably have to assume a bag-of-attribute-assertions
> as well.  While it is OK to put the "one-and-only" restriction on
> birth-date, it might be quite reasonable to have several assertions
> about birth-date.
> (Actually this example is a bit more complicated.  You probably don't
> really want to write rules about birth-date.  The laws or business rules
> are about age, so your rule condition would say "age >= 18".  But the
> request context might only have values or assertions about birth-dates.
> In that case the PDP needs additional information to reach a decision.
> That's another interesting topic.)
> No change to the policy language is required; however, section 7 of the
> spec would have to specify the required behavior, which might be tricky.
> A PDP implementation could, for example, use a Prolog library to test a
> rule condition, "bday < 1992-10-22" against the assertion "bday <
> 1990-10-01" to return "true".  But this sort of inference depends on
> axioms and rules of deduction outside of XACML.
> I don't have Greg's email.  If anyone has his email, please forward to
> him.
> 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]