MHonArc v2.5.0b2 -->
xacml message
[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..Forwarded message from Scott Cantor.
--- Begin Message ---
(feel free to forward)
> I see this as a protocol layering issue: the SAML Status and
> Conditions should contain Status and Conditions associated with
> the SAML envelopes, and not with the processing of their
> payloads. The payloads are a different protocol layer and
> contain self-contained XACML Request and Response elements.
> Their Status and Obligations elements are associated with the
> processing of the payload itself.
You're mixing SAML layers here. The SAML Status addresses the result of
processing the protocol request, which in this case is an XACML Query
message containing an XACML Request. That is its purpose, there would be no
other "status" to represent in SAML.
Meanwhile, Conditions is something else entirely. It's part of the assertion
you get back, so it's not a protocol element. It has some obvious sorts of
parallels to Obligations.
In the same vein, I'd argue that XACML's Status is the result of processing
the XACML Request, and Obligations is part of the XACML "result", which I
saw as a statement in an assertion.
If all you wanted to do was reuse the SAML protocol binding work, you
wouldn't even need an assertion. You could just define a new XACMLResponse
that extends SAML's StatusResponseType and directly contains the Decision
and Obligations. And again, having a second Status element would be
confusing there.
But I think the point is to wrap the XACML Decision and Obligations in an
Assertion, in which case I don't see the XACML Response as the optimum
payload for the statement.
> Another alternative is that we require the XACML Status and
> Obligations to be duplicated in the SAML Response/Status and
> Assertion/Conditions. This has the problem that a single XACML
> Response may have multiple <Result> elements, each with its own
> Status and Obligations. 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.
> In the current XACML Profile for SAML, the XACML Response from
> evaluating the payload of an XACMLAuthzDecisionQuery would be
> part of an XACMLAuthzDecisionStatement, which would be put into a
> SAML Assertion, and then into a SAML Response. Similarly for
> XACMLPolicyQuery. The current Profile defines only the Statement
> levels, but should probably add a description of the packaging
> into an Assertion and a Response. That description can deal with
> the SAML Status and Condition elements.
That I would agree with, but Conditions is a different animal from Status
and probably doesn't need any mention here. One way or the other it needs to
be clear what the relationship is.
-- Scott
--- End Message ---
--
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]