Skip to Content.
Sympa Menu

mace-opensaml-users - RE: AttributeQuery use cases

Subject: OpenSAML user discussion

List archive

RE: AttributeQuery use cases


Chronological Thread 
  • From: Mike Ferraro <>
  • To: Scott Cantor <>
  • Cc:
  • Subject: RE: AttributeQuery use cases
  • Date: Fri, 27 Aug 2004 12:21:32 -0400

Quoting Scott Cantor
<>:
> This is because the default value handler is very limited. Probably too
> limited, I could have special cased an empty element and handled it as an
> empty string, so please file a bug on it. But you can always just install
> your own attribute class to handle everything, and any non-trivial use case
> requires that anyway.

Ok. I'll file a bug and you can decide if it's something that you want to
include. I would have added my own attribute handling, but I wanted to try to
avoid extensions for compatability and maintenance purposes (i.e. new opensaml
releases and the like).

> In practice though, I don't see a lot of value in passing empty strings or
> null values (or even zero values) in an application using SAML. It doesn't
> make a great deal of sense to me. Just don't pass the attribute, since
> you're not asserting anything of significance anyway.

We're building an attribute service and if I ask for someone's email address,
a value of empty has a different meaning than simply not returning an
attribute. An empty email address means that the attribute is valid, but the
Subject does not have one on record. An unreturned attribute means
that the email address attribute does not exist in the authority. The
distinction is subtle, but is one that I wanted to make.

> Both string and anyType are allowed to be empty (though not "nil"), subject
> to the point above that it seems a waste of XML. The SAML rule of thumb
> about not using empty strings wasn't really intended to be about attribute
> values.

Ok. I was just going by what was in the docs:
1.2.1 String and URI Values
All SAML string and URI reference values have the types xsd:string and
xsd:anyURI respectively, which
are built in to the W3C XML Schema Datatypes specification [Schema2]. All
strings in SAML messages
MUST consist of at least one non-whitespace character (whitespace is defined
in
the XML
Recommendation [XML] ยง2.3). Empty and whitespace-only values are disallowed.
Also, unless otherwise
indicated in this specification, all URI reference values MUST consist of at
least one non-whitespace
character, and are strongly RECOMMENDED to be absolute [RFC 2396].

> What is the actual significance of such an assertion? What could I do with
> it?

Well, the current options for receiving attribute data are: Send a valid
string
or don't send anything. Since both responses MUST include a SUCCESS status
message, the ability to respond with an empty string would signify that the
attribute was valid but that it contained no data. Without that ability, not
sending an attribute could mean no data or it could mean that the attribute
was
invalid. As a client, it would be helpful to be able to determine whether
there was some sort of error (requesting an invalid attribute) or simply no
data.

I guess that another way to handle this would be to return some custom
substatus
code values. That would seem to get complicated though, especially if
specific
attributes needed to be identified.

> I can't see any use for the distinction, but other people have more
> imagination than me.
>
> Anyway, I can pretty easily special-case an empty element and turn it into
> an empty string, which is what it is. If it's a major issue, I can apply the
> fix to 1.0.

That would be ideal. I wouldn't want the code changed just because I need a
special case, but it seems that the library should allow for an empty anyType
AttributeValue if the SAML/XML specs say that it's valid.

-Mike



Archive powered by MHonArc 2.6.16.

Top of Page