Re: [security-services] Comments onsstc-saml-x509-authn-attrib-profile-draft-11

[Greg Whitehead <greg.whitehead@hp.com>]

Looking at section 3.3.4 of SAML2 core:

"If the SAML authority cannot provide an assertion with any statements
satisfying the constraints expressed by a query or assertion reference, the
<Response> element MUST NOT contain an <Assertion> element and MUST include
a <StatusCode> element with the value
urn:oasis:names:tc:SAML:2.0:status:Success".

Doesn't that apply in this case? If you have no attributes to return then
you have no AttributeStatement, and so you would omit the Assertion (rather
than including an empty Assertion).

-Greg

On 2/14/07 10:29 AM, "Ari Kermaier" <ari.kermaier@oracle.com> wrote:

> I suppose it's bad form to upload a draft and then post comments on it myself
> the next day, but I noticed something that might bear discussion and
> modification.
> 
> The X.509 attribute sharing profile discusses requirements for a successful
> samlp:Response to the samlp:AttributeQuery, and defines behavior w.r.t.
> presence/number of saml:Assertion and saml:AttributeStatement elements.
> 
> In both sstc-saml-x509-authn-attrib-profile-cd-02 [lines 174-176] and
> sstc-saml-x509-authn-attrib-profile-draft-10 [lines 184-186], it requires a
> successful Response to have exactly 1 Assertion, and exactly 1
> AttributeStatement.
> 
> Mailing list and meeting discussion threads arrived at the conclusion that
> there was no need to restrict a Response from carrying multiple Assertion
> and/or AttributeStatement elements. Thus, I modified the language in
> sstc-saml-x509-authn-attrib-profile-draft-11 [lines 185-186] to read:
> 
> "Any <Assertion> element(s) MUST satisfy the following conditions:
> The <Assertion> element MUST contain at least one <AttributeStatement> element
> that conveys the attributes of the principal to the service provider."
> 
> Thinking about implementation, however, caused me to have second thoughts
> about this language:
> 
> Since the [SAMLCore] schema requires at least 1 Attribute element in an
> AttributeStatement, a response in which none of the requested user attributes
> could be returned (e.g., the attributes do not exist) could not have an empty
> AttributeStatement. This means that, according to either the new or old
> language, the Response could not contain an Assertion with no
> AttributeStatement; the new language provides the ability to omit the
> Assertion entirely in this case.
> 
> But is this the best behavior? The case of no Attributes to return might be
> better handled by returning a Response containing an Assertion (with the
> correct Subject) but with no AttributeStatement. Maybe the new language should
> be changed to require 1 or more Assertions in a successful response, but allow
> 0 or more AttributeStatements.
> 
> Thoughts?
> 
> Thanks,
> Ari Kermaier
> Oracle
>