[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Attribute values or the lack therof
Oops - somehow caused the incomplete message to be sent - here's the completed message: > -----Original Message----- > From: Philpott, Robert > Sent: Tuesday, September 02, 2003 6:23 PM > To: 'Jim Christopher'; 'saml-dev@lists.oasis-open.org' > Subject: RE: Attribute values or the lack therof > > 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 seems to be: 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 x > > 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]