Shibboleth Developers

["Scott Cantor" <>]

> In the AttributeMap file, one field must be populated (and correctly) or
> the attribute is thrown away, it is the "nameFormat" field.  If it is
> missing or populated incorrectly (I had it missing and used "unspecified"
> before I finally populated it correctly), the attribute is filtered out of
> the assertion and as far as I can tell nothing shows up in the logfile to
> mention the assertion is being ignored.

Logging is probably horrid, but the reason it's filtered is that we on this
project feel that non-URI names are evil. To express this revulsion, I make
life hard for people that use non-URI naming by defaulting the nameFormat to
either the SAML 2.0 URI string or the Shib custom Namespace we defined. If
you leave it out, that's what it's trying to match when it looks at the
attributes.

(It's logical for you to assume that omitting it == unspecified.)

> The second thing might be more of a discussion topic (and I have a feeling
> the natural response is going to be, that the IDP I am using is not
> following the standards, and while that may be true, it seems like this
> might be something the SP should handle).  When an attribute is
> sufficiently "complex", this IDP escapes the attribute with a CDATA
> wrapper (<![CDATA[<data here>]]>).  The question I guess is how should the
> Shibboleth SP handle attribute values presented in this way?

Yeesh, I've never seen CDATA used in SAML before. I imagine it's not a Text
node in the DOM, that's why the default decoders skip it.

I could easily say "that's what custom decoders are for", but I'll see what
I can do about it.

Thx,
-- Scott

PS. I take it you got artifact to work after we chatted?