RE: XACML extensions to SAML. Forwarded message from Scott Cantor.

[Anne Anderson <Anne.Anderson@Sun.COM>]

On 28 July, Scott Cantor writes: RE: XACML extensions to SAML. Forwarded message from Scott Cantor.
 > > Another alternative is that we require the XACML Status ...
 > > to be duplicated in the SAML Response/Status ....
 > > This has the problem that a single XACML
 > > Response may have multiple <Result> elements, each with its own
 > > Status ...  I think we would have to require a
 > > separate SAML Statement, Assertion, and Response for each
 > > <Result> element if we take this approach.
 > 
 > This is why I think this is messy, but it's much cleaner if you just place
 > multiple Decision/Obligation elements directly in your new statement type
 > and leave the Status processing to SAML. If you're doing a status, then
 > you're embedding an application protocol inside SAML's application protocol,
 > and that's why it's messy.

XACML allows a single XACML <Request> to request access to
multiple Resources (by the same Subject and for the same Action).
The semantics are that the PDP does a separate evaluation of the
policies for each Resource; the <Result> that corresponds to each
individual Resource in the <Response> must be the same as the
<Result> that would be obtained if a Request were submitted for
that Resource by itself.  All the <Result> elements, one for each
submitted Resource, are packaged into a single XACML Response.

The XACML <Status> can be different for each XACML <Result> that
is returned, since they are evaluated independently by the PDP.
The PDP evaluation for one Resource may have run into a
divide-by-zero error or an unreachable-subpolicy error, and thus
the <Status> field in its corresponding <Result> would reflect
that.  The PDP evaluation for another Resource, that was
submitted as part of the same Request, might never have
encountered those pieces of the policy and so might evaluated
completely successfully.

One of XACML's strengths is that the combining algorithms treat
errors explicitly.  The handling of errors is built in to the
policies.  We don't just pop up from the evaluation and say "Game
over" when an error occurs.  To me, this makes error status an
integral part of the decision, and not the responsibility of
another protocol layer.

I think for most types of payload, the error status is properly
the responsibility of the SAML protocol layer, and should be
reflected there.

It seems to me that the SAML Status for an XACML Response could
be one of two values:

  No errors occurred
  At least one error occurred

Anne
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692