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