[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: XACML extensions to SAML. Forwarded message from Scott Cantor.
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