Re: [xacml] Comments on Attribute predicate profile for SAML andXACML

[Paul Tyson <phtyson@sbcglobal.net>]

On Mon, 2011-04-04 at 15:26 +0200, Gregory Neven wrote:
> Hi Paul,
> 
> Thanks for your comments, responses are in-line.
> 
> > 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.

> 
> > 2. I had to read closely to determine that the required return type of
> > the AttributePredicate/Apply/@FunctionId is boolean.  Consider putting
> > this earlier in the description.
> 
> Okay, will do.
> 
> > 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.
> 
> I agree that the semantics of having multiple predicates in a 
> query/assertion is equivalent to an AND over the same predicates. 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.

I don't think such hypothetical use cases justify defining
AttributePredicateQuery as a conjunctive list.  You're adding a built-in
logical construction in an area that should be completely user-defined.
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.

> 
> > 4. I'm not too familiar with SAML, so I assume that the
> > samlp:Status/samlp:StatusCode/@Value attribute is the conventional way
> > to confirm or deny a SAML assertion?  For the purpose at hand it seems
> > like a roundabout way of communicating the truth-value of a
> > (potentially) complex predicate.  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.
> 
> When a predicate is not explicitly included in the response, is it still 
> possible to have the description of the predicate (and not just some 
> ID/reference to it) be signed by the XML Signature? If so, then you're 
> right, one could make the predicate optional in the response. If not, 
> 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.

> 
> > 5. Some of the preceding comments are to support a scenario that is not
> > addressed in your proposal but was mentioned in the TC call of
> > 2011-03-24.  That is, allow the PDP during the course of its evaluation
> > to call an IDP to evaluate an AttributePredicateQuery.  The content of
> > the query could be a literal chunk of the policy being evaluated, or a
> > partially-processed chunk (e.g. with known attribute values in place of
> > AttributeDesignator elements).  In either case, the query would have to
> > conform to the restrictions given in the profile.  I would favor a very
> > slim XACML profile to specify this sort of behavior--but I'm not sure
> > just what needs to be specified, as it is really just an implementation
> > option.  It does not affect the specified result of policy evaluation or
> > add any syntactic or functional features to the XACML core.
> 
> I'm not sure I understand your point here. Which "restrictions given in 
> the profile" do you mean, those specified in section 3.2 of our draft? 
> Which sort of behavior do you exactly mean?

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.

> 
> > 6. Policy evaluation using AttributePredicateQuery seems to obviate the
> > need for local/global attribute mapping.  Weren't local boolean
> > attributes introduced as a feature of an earlier design solution for
> > this problem?  Now that the design has advanced further, they are not
> > needed.  If however, there are real use cases requiring them, you should
> > specify how to bind the local boolean attribute to the predicate over
> > global attributes.  Your draft specifically excludes this mechanism from
> > standardization, but that is exactly the point that would facilitate
> > interoperability.  I have some ideas on that but will hold until the
> > requirement is confirmed.
> 
> Do you mean that the attribute predicate profile as specified in our 
> draft obviates the need for the local/global attribute mapping? I 
> actually don't think so. As discussed before, there are some research 
> challenges to be solved to feed the attribute predicates straight to the 
> PDP and let the PDP decide whether they imply the policy or not. (Cf. 
> the Prolog-style statements you once illustrated on the Wiki.)  As long 
> as we haven't tackled those issues, the local/global translation 
> solution is the best we have.

In the scenario I described above, the PDP is just outsourcing a bit of
the policy evaluation, perhaps to minimize exposure of a particular
attribute value outside of the IDP.  If that is possible, I don't see
what is the requirement for local attributes standing in for attribute
predicates.  This scenario does not require the request context itself
to contain attribute assertions nor does it require the PDP to evaluate
policy expressions against attribute assertions.  The IDP does all the
hard work by evaluating AttributePredicateQuerys.

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.

Regards,
--Paul
  
> 
> Greg
>