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


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]