RE: Attribute values or the lack therof

["Philpott, Robert" <rphilpott@rsasecurity.com>]

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.