OpenSAML user discussion

["Scott Cantor" <>]

> Irrelevant?, I thought the issuer content had to be the entity issuing
> the assertion (which happens to be the one authenticating the user, in
> my case, if I'm not badly mistaken).

I mean it's irrelevant how that value lines up with your business
relationships, as that's not a SAML issue. All SAML does is mandate that the
value is a unique name (a URI) that can be matched up to metadata about the
issuer.

For example, without metadata, you can't start SSO at the SP, because you
don't know where to send the user. You also can't use the artifact binding,
because you don't know where to resolve the artifact. Etc.

The certificate alone doesn't give you any of that, so you have to limit
your feature set to a fairly constrained subset. Sometimes that's what
people want, but sometimes they don't understand enough to know what they
want.

> Anyway, the issuer content it's
> not an uri, so it can't be an entityID, AFAIK (it has unescaped
> whitespace something like
> <saml:Issuer> Project - Workplace Center name</saml:Issuer>
>  without even a format attribute).

In SSO (and that's all I'm talking about here), that would be illegal, yes.

> So Ok, I understand opensaml is meant to deal with compliant SAML
> assertions, not with this. I'm just commenting this because I don't
> know whether opensaml should detect this and fail validation. Or fail
> marshalling or something. I suspect the assertion has been generated
> (ab)using opensaml for java.

OpenSAML can't know whether the profile in use requires a particular kind of
Issuer.

> I don't know how easy it is to check issuer syntax, because the
> content syntax depends on the format attribute. It's best for me that
> it does not fail validation, so I'm fine with what it does now, but
> for opensaml in general, I don't know.

If you turned on schema validation, as Chad said, it would fail. If you were
using OpenSAML 1.1, it would have failed already.

> Thanks for confirming I'm in a world of pain, and it's just not me
> being stupid and feeling undue pain. :(

The lack of Issuer guidance in SAML 1.x is why that spec was so difficult to
interop. Naming coherency in 2.0 is IMHO the single most important change.

-- Scott