Robert et al;
> 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?
That's part of what I was trying to convey. In order to indicate that an
attribute had no-value ( "", null, nil, Nothing, etc. ), early on we simply
did not include an attribute designator in the response; this quickly proved
inadequate because we also made a practice of omitting attributes to which
the requester is not authorized in order to prevent sniffing. This made it
difficult for the requester to determine the meaning of the response: does
the missing attribute mean the attribute has no value, or does it mean the
requester does not have authorization to query for that attribute? In short
we found a need to distinguish between returning-a-value-of-nothing ( per
David's post ) and returning-nothing ( per the sniffing discussion ). So we
opted to define a "no-value" attribute value to distinguish the two cases.
> 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'm sure you are correct. The "URN" is by no means indended for public
consumption, but instead as a reference for the closed-community of our
application vendors. In light of your comments and those of Scott Cantor,
however, I have requested that our team review the use of URIs in our
service.
> 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
+1
If the AttributeValue element were nillable, perhaps?
> 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>.
Our interpretation comes from the second and third sentences of that section
( 1.2.1 ): "All strings in SAML messages MUST consist of at least one
non-whitespace character .... Empty and whitespace-only values are
disallowed.", which we took as precluding us from returning an empty
AttributeValue element to indicate no-attribute-value.
One option that just occurred to me that we didn't consider during
implementation - since the AttributeValue is defined as type xsd:anyType, it
seems to me that we should have defined an element in our namespace to
represent no-value. Something like so:
<AttributeValue><null
xmlns="http://www.learningstation.com/services/security/SAML" xsi:nil="true"
/></AttributeValue>
I suppose we got stuck on the notion of the no-value being a simple type.
This feels better than the URN solution we have now, but I'd still prefer to
nil the AttributeValue element directly.
> I'm not in favor of introducing a separate URN to distinguish the
null/empty
> value.
To be frank the URN leaves a bad taste in our mouths as well; I wasn't
advocating its use, just informing the group of the solution we came up with
for the problem.
jim christopher
senior developer / r&d
learningstation
