[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 value. Comments? 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 list... Rob Philpott RSA Security Inc. The Most Trusted Name in e-Security Tel: 781-515-7115 Mobile: 617-510-0893 Fax: 781-515-7020 mailto:rphilpott@rsasecurity.com > -----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]