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 onsstc-saml-x509-authn-attrib-profile-draft-11


Correct. Though I would add that there are situations where the query can be processed, but an error condition would still exist. For example, if the Subject in the query could not be resolved to a principal known to the authority, then a secondary error status of UnknownPrincipal would be appropriate.
::Ari

> -----Original Message-----
> From: Greg Whitehead [mailto:greg.whitehead@hp.com]
> Sent: Wednesday, February 14, 2007 3:26 PM
> To: Tom Scavo
> Cc: Ari Kermaier; security-services@lists.oasis-open.org
> Subject: Re: [security-services] Comments on
> sstc-saml-x509-authn-attrib-profile-draft-11
> 
> 
> 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]