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

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

Comments from SSTC member on XACML Profile for SAML on how we
would handle the SAML Status and Conditions elements.

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.

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.

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.

Here are the current SAML Response and Status schema fragments.

    <element name="Response" type="samlp:ResponseType"/>
    <complexType name="ResponseType">
    	<complexContent>
            <extension base="samlp:StatusResponseType">
                <choice minOccurs="0" maxOccurs="unbounded">
                    <element ref="saml:Assertion"/>
                    <element ref="saml:EncryptedAssertion"/>
                </choice>
            </extension>
    	</complexContent>
    </complexType>
    <complexType name="StatusResponseType">
    	<sequence>
            <element ref="saml:Issuer" minOccurs="0"/>
            <element ref="ds:Signature" minOccurs="0"/>
            <element ref="samlp:Extensions" minOccurs="0"/>
            <element ref="samlp:Status"/>
    	</sequence>
    	<attribute name="ID" type="ID" use="required"/>
    	<attribute name="InResponseTo" type="NCName" use="optional"/>
    	<attribute name="MajorVersion" type="integer" use="required"/>
    	<attribute name="MinorVersion" type="integer" use="required"/>
    	<attribute name="IssueInstant" type="dateTime" use="required"/>
    	<attribute name="Recipient" type="anyURI" use="optional"/>
    </complexType>
    <element name="Status" type="samlp:StatusType"/>
    <complexType name="StatusType">
        <sequence>
            <element ref="samlp:StatusCode"/>
            <element ref="samlp:StatusMessage" minOccurs="0"/>
            <element ref="samlp:StatusDetail" minOccurs="0"/>
        </sequence>
    </complexType>
    <element name="StatusCode" type="samlp:StatusCodeType"/>
    <complexType name="StatusCodeType">
        <sequence>
            <element ref="samlp:StatusCode" minOccurs="0"/>
        </sequence>
        <attribute name="Value" type="anyURI" use="required"/>
    </complexType>
    <element name="StatusMessage" type="string"/>
    <element name="StatusDetail" type="samlp:StatusDetailType"/>
    <complexType name="StatusDetailType">
        <sequence>
            <any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
    </complexType>

--- Begin Message ---

• From: Scott Cantor <cantor.2@osu.edu>
• To: Anne.Anderson@Sun.COM, 'Eve Maler' <Eve.Maler@Sun.COM>
• Date: Tue, 27 Jul 2004 23:54:18 -0400

> It seemed very straightforward with the current SAML 2.0 Request
> and Statement types.  If you want to look them over (as a proof
> of concept for SAML 2.0 extensibility), they are attached.
> Comments are VERY welcome.

Seems to be reasonable based on my memory of what the requirements were.
IIRC, the main issue I had was with the duplication of protocol-related data
in the XACML Response element, like a status code, but I think that's been
made optional for 2.0? Does the XACML SAML profile for carrying this inside
a SAML protocol exchange specify to use the SAML Response for handling the
status, or is it like an "XACML processing status" that's distinct from the
protocol?

I guess terminology-wise, it's still potentially confusing:

samlp:Response
	samlp:Status
	saml:Assertion
		xacml:XACMLAuthzDecisionStatement
			xacml:Response
				xacml:Status

Is it reasonable to consider just putting the xacml:Decision and
xacml:Obligations elements directly in the new statement type? That seems
like it aligns more directly to the SAML authz statement type, just with
more functionality.

-- 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