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: FW: Attribute values or the lack therof

Oops - a fat finger caused my incomplete message to be sent - here's the
completed/corrected message:
Re: sniffing out semantics - I think this is really a separate issue.  If
the requester is not authorized to see an attribute, I think the attribute
should just not be returned in the assertion.  A "sniffer" still won't be
able to tell the difference between an attribute that doesn't exist and an
attribute they are unauthorized to see. Or did I miss something?

The main issue David is raising is: When I'm authorized to see an attribute,
and that attribute really has a null/empty string value, it can't be sent to
me in the assertion according to section 1.2.1.

You have dealt with this issue by defining the proprietary URN.  The rules
about defining proprietary URN's has always been a bit fuzzy to me, but I'm
not sure that doing what you did conforms to URN registration "rules".
Perhaps someone better versed in URN namespace definitions can elaborate.  

I think the "right" solution to this issue is to fix the SAML spec by
permitting an AttributeValue element to be returned as an empty element -
i.e. <AttributeValue/>.  One "might" say that this is already allowed by
declaring that section 1.2.1 does not apply to the "user" data provided in
this element.  Section 1.2.1 starts out with the sentence "All SAML string
and URI reference values have the type xsd:String and xsd:anyURI,
respectively...".  So one could just say that the attribute value data is
not a "SAML string".  Thus it can be permissible to send an empty element
for <AttributeValue>.

I'm not in favor of introducing a separate URN to distinguish the null/empty


p.s. I've CC'ed the main TC list in case some folks there aren't on saml-dev
and we need to possibly add this to a 1.1 errata and to the v2.0 edit

Rob Philpott 
RSA Security Inc. 
The Most Trusted Name in e-Security 
Tel: 781-515-7115 
Mobile: 617-510-0893 
Fax: 781-515-7020 

> -----Original Message-----
> From: Jim Christopher [mailto:jchristo@carolina.rr.com]
> Sent: Tuesday, September 02, 2003 5:41 PM
> To: saml-dev@lists.oasis-open.org
> Subject: Re: Attribute values or the lack therof
> Warren [ et al. ];
> We have the same situation.  We used to leave the no-value attributes out
> of
> the response in order to prevent a requester from sniffing out semantics
> of
> our service they are not authorized to use.  The drawback is that our
> service behaves the same way when a requester specifies an attribute the
> service doesn't recognize.  That is, it's impossible to tell from our
> response whether a request contained an unrecognized attribute name or if
> the attribute value is "saml-null".  Like all humans our service users
> make
> mistakes, so we opted to define a URN to represent the "saml-null" value (
> e.g., urn:learningstation:names:entity-types:null ) and instructed our
> service users to recognize that value.
> Doing this actually helped us solve several other issues in our SAML
> service.  The service applies policy to every request based on the
> requester, the type of request being made ( e.g., attribute, authorization
> decision, or authentication query ), and the resource URN if applicable.
> We
> didn't have a way to specify the security policy for a resource-less
> attribute query vs. an attribute query with an empty resource, for
> instance,
> until we had a way to identify ( internally ) a "saml-null" value.
> HTH,
> jim christopher
> senior developer / r&d
> learningstation
> ----- Original Message -----
> From: "Warren, David" <dwarren@rsasecurity.com>
> To: <saml-dev@lists.oasis-open.org>
> Sent: Tuesday, September 02, 2003 5:00 PM
> Subject: Attribute values or the lack therof
> > Hi fellow SAML'ers,
> >
> > How should an implementation send an empty value (i.e. like a NO-VALUE
> value
> > in a database) for an attribute?  The first idea I had was to send an
> > Attribute element with no AttributeValue but that seems to be explicitly
> > forbidden by the schema (no minOccurs attribute which means 1 is
> required,
> I
> > think).  The second idea I had was to just specify an empty element
> (like
> > <AttributeValue/> or <AttributeValue></AttributeValue>) but section
> 1.2.1
> of
> > the core spec (Assertions and Protocol, etc.) seems to disallow this.
> >
> > A similar problem comes up with trying to send an empty string (i.e.
> "").
> >
> > Have any other implementers solved this?
> >
> > David
> > --
> > Obligatory .signatory
> > David Warren       phone: 781-515-7152
> > RSA Security Inc., 174 Middlesex Turnpike, Bedford, MA 01730
> > dwarren@rsasecurity.com
> >
> >
> > To unsubscribe from this list, send a post to
> saml-dev-unsubscribe@lists.oasis-open.org.
> >
> >
> To unsubscribe from this list, send a post to saml-dev-
> unsubscribe@lists.oasis-open.org.

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