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] Comments on Attribute predicate profile for SAML andXACML

Hi Paul,

>>> 1. A suggestion for writing the SAML profile: instead of specifying the
>>> evaluation of AttributePredicate with reference to a hypothetical XACML
>>> policy evaluation, maybe you could just refer to section 7.4 of the
>>> XACML spec for how to evaluate expressions.
>> I guess we could, but Section 7.4 in the XACML spec seems somewhat
>> short. Especially how AttributeDesignator elements need to be treated
>> seems to need a bit of clarification, don't you think?
> I agree, but you don't--and shouldn't--clarify the behavior in the
> profile.  As I understand it, you don't intend to change the semantics
> of the xacml expression elements that are used in
> AttributePredicateQuery. So you should refer to the XACML spec for how
> to evaluate them.

Okay, but then the profile would at least mention against which request 
context the predicate needs to be evaluated, no? I.e., the context 
containing all known attributes about the subject.

>>> 3. Is it necessary to allow multiple AttributePredicate elements in a
>>> query?  It seems simpler to have the relying party wrap its predicates
>>> in an "and" function if they want this behavior.
>> [...] When
>> using the local/global attribute mapping that we proposed for XACML,
>> though, it is quite likely that one may need assertions for multiple
>> predicates (corresponding to multiple local variables). It makes sense
>> to bundle the queries/responses for all these predicates in a single
>> query/response.
> [...]
> By comparison, the XACML Condition element only allows one top-level
> expression.  The XACML Target element is defined as a conjunctive list,
> but it serves a different purpose, and has some history behind it so it
> is somewhat justified.

I guess I'm too "young" in this TC to know about the history of the 
Target element ;-) but I can see your comparison to the Condition 
element. I actually presented the same issue to the SAML TC during their 
call last Tuesday, and there people seemed to agree with you as well. So 
let's restrict to a single AttributePredicate per query/assertion, as 
you suggested.

>>> 4. [...] Rather than just echoing the predicate
>>> back to the relying party, could there be a dedicated
>>> AttributePredicateResponse with Result=true|false?  Optionally, the
>>> predicate could be returned as well.  This would be analagous to the
>>> XACML Response, with optional return of the Request attributes.
>> [...]
>> then there's a danger that, if the PEP and IDP communicate over an
>> insecure connection or through redirects via the user, an adversary
>> replaces the queried predicate with a fake predicate and so that a
>> "true" response from the IDP would be misinterpreted by the PEP as being
>> for the real predicate instead of the fake predicate.
> Transmission-level security is not my strong suit, but I would think
> there would be other, better ways to protect and verify the
> communication.  Apparently the SAML communication idioms are different
> from XACML, so I will stay out of this part.

You're right though that there are communication settings in which a 
yes/no response would do. I would insist that the IDP should at least 
have the option to include the predicate in the assertion in other 
communcation settings, but I guess by making it optional, all 
communication settings can be dealt with in the most efficient way.

> Here is the scenario: while evaluating a policy with respect to a
> request context, the PDP realizes it cannot evaluate an expression
> because it does not have a value for a particular subject attribute, and
> it cannot fetch the value from a PIP.  It does, however, know about an
> IDP that can handle this particular attribute and can respond to an
> AttributePredicateQuery.  So the PDP carves out the entire Apply
> expression in which that attribute occurs, resolves AttributeDesignators
> that it does know about (replacing them with AttributeValues), forms an
> AttributePredicateQuery containing the Apply element, and ships it off
> (along with the subject identifier) to the IDP.  It gets the return
> value and continues with its policy evaluation, marking the Apply
> element as true or false (or indeterminate) based on the saml:Response
> to the AttributePredicateQuery.  The effect is exactly the same as what
> you describe, but without the need for a local boolean attribute.

After your clarifications during the call, I now better understand your 
point how this approach eliminates the need for local/global attribute 
translation. So you're suggesting that the PDP, during the policy 
evaluation, calls out directly to the IDP with an attribute predicate 
query taken from the Condition. But there are no predicates being passed 
in the request context, and the PDP does not have to perform 
"intelligent matching" between predicates in the request context and in 
the policy.

Then the only remaining issue is _which_ Apply expression the PDP 
"carves out". I already discussed this issue and possible solutions on 
slide 14 of 
Namely, the PDP could use (in order of increasing privacy-friendliness) 
the lowest Apply statement with a boolean return type, a higher-up Apply 
statement with boolean return type and containing only 
AttributeDesignator with the IDP as issuer, or the entire Condition. We 
could leave it up to the implementation of the PDP to decide which 
strategy it follows.

> I believe AttributeAssertions in the request context (as I described on
> the wiki) would still provide a nice architectural option, but more
> research is required to put all the pieces together.

I absolutely agree.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]