OpenSAML user discussion

[Mike Ferraro <>]

Quoting Scott Cantor 
<>:
> > Given the following schema constraints:
> >
> > 1. AttributeStatements MUST contain at least one Attribute element.
> > 2. Attribute elements MUST contain at least one AttributeValue element.
>
> This is fixed in 2.0.

Ok, but I'm guessing that an OpenSAML library with SAML 2.0 support is a long
ways in the making.  In using the OpenSAML 1.0 library, I still have an issue.
What I'm trying to figure out is if there is a proper solution for this.

> > 3. AttributeValue elements CANNOT contain null or empty strings.
>
> This is a little too strict a reading, IMHO. There's no reason not to allow
> empty strings in this case, and the schema certainly permits it.

That's what I thought, but the OpenSAML 1.0 library chokes when I send an 
empty
AttributeValue element.  And by choke, I mean that it spits out a warning
message:

[ WARN] [27 Aug 2004 09:54:18,288] rejecting an AttributeValue without a
simple,
non-empty text node
[ WARN] [27 Aug 2004 09:54:18,288] exception while instantiating a
SAMLAttribute: Attribute invalid, requires name and namespace, and at least 
one
value

And it does not create a SAMLAttribute object for the returned attribute.
Here's an example of a response that generates this message...

<attributeStatement>
  <Subject>
    <NameIdentifier NameQualifier="..." Format="...">
      username
    </NameIdentifier>
  </Subject>
  <attribute AttributeName="givenname" AttributeNamespace="...">
    <attributeValue></AttributeValue>
  </Attribute>
  <attribute AttributeName="sn" AttributeNamespace="...">
    <attributeValue></AttributeValue>
  </Attribute>
  <attribute AttributeName="mail" AttributeNamespace="...">
    <attributeValue></AttributeValue>
  </Attribute>
</AttributeStatement>

The type for an AttributeValue is anyType.  Is "empty" a valid value for
anyType?  I would think so, but in researching the type in the XML Schema 
docs,
I'm not so sure anymore.  I know that the string type is not allowed to be
empty
or contain only whitespace.

> Returning strings to mean null would be awful. Just about the worst thing
> you could do, I would say, and certainly would be completely unintelligible
> unless you programmed both ends. The limitation of the schema means that
> returning an attribute with no values is essentially impossible until 2.0.

I completely agree, but I'm at a loss due to the inability to convert
an empty AttributeValue.

> But there's no way to distinguish a NULL value from the empty string. But a
> null value is really "no value" and that's the thing 1.x doesn't support.
>
> > One question is if there is a true difference between cases A and B.
>
> I wouldn't think so in the typical cases.

I have been leaning towards this resolution too.  I'm just getting pressure
from
"above" to provide a distinction between "invalid", "null", and "empty".  
Thus,
the different possible solutions in my email.  If I can convince the higher
powers that "invalid" and "null" can both most likely be treated as "does not
exist" and simply not returned, then that will at least get rid of part of my
dilemna.

> > Another is if sending back actual string values for null and empty strings
> > could be problematic if "NULL" and "NOVALUE" are actually possible values.
>
> That would just be terrible for all the obvious reasons.

So true.

-Mike