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


So that probably means this line from the Deployment Profile I posted
previously needs work:

If the identity provider is unable to resolve attributes for this
principal (for any reason), it MUST return an error.

This probably needs clarification along the lines you describe below.
Do you agree?

Thanks,
Tom

On 2/14/07, Greg Whitehead <greg.whitehead@hp.com> wrote:
> I think Success follows from being able to interpret and execute the query,
> even if the query returns no results. Failure should be reserved for cases
> where there is a problem interpreting or executing the query.
>
> It's not unlike doing a SQL query "select * from foo" and getting back an
> empty result set vs an error in the query syntax or an error connecting to
> the database.
>
> -Greg
>
>
> On 2/14/07 2:19 PM, "Tom Scavo" <trscavo@gmail.com> wrote:
>
> > 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]