OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [security-services] Comments on sstc-saml-x509-authn-attrib-profile-draft-11


I agree that no attributes implies no assertions but what constitutes
"Success" in the case of AttributeQuery?  Put another way, under what
conditions is the StatusCode something other than
"urn:oasis:names:tc:SAML:2.0:status:Success"?

Thanks for the clarification,
Tom

On 2/14/07, Greg Whitehead <greg.whitehead@hp.com> wrote:
> 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
> >
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]