Shibboleth Developers

["Scott Cantor" <>]

> Well, it does insofar as a particular syntax check depends on the
> format.  That's why the format handlers are such a clean solution to
> this problem.

Right, but where you see syntax checking as a problem to solve, I see it as
mostly irrelevant because in SAML land nobody cares. They're just strings. I
guarantee the products out there would take anything you threw at them no
matter the format, until it actually mattered on the back-end.

> Ouch.  That totally defeats the purpose of this exercise.

Then we're talking past each other. The point of name mapping to me is to
map between local and federated names, not to enforce syntax. When that
involves a simple text transform, as in these cases, it's a trivial task.

> > Or if you like, implement
> > it in the mapping plugin if you care about it.
> 
> I don't see how to do that as cleanly as the SAMLNameIdentifier hooks,
> but okay if you say so. ;-)

No, it's not clean, I'm not saying that it is. It will be in 2.0, because of
the Validation layer, but that's what I'm getting at...the only thing that
hook buys you in this code is something that's going to be handled
differently in the future, thus no harm done when that change happens.

> No, this is not true.  The 'template', which is what Shib uses on the
> front end to produce the name identifier, is a simple macro-expanded
> string.  It's not a pattern, and doesn't guarantee that the name
> identifier produced by the plugin is valid.  It can't, since you don't
> know in advance what the string will be after macro expansion.

99.9% of the time it will be right if you know what the possible username
space looks like, though.

> The 'regex' is a bona fide pattern, but it is not used to check the
> syntax of the name identifier, it's used to reverse the macro
> expansion.

I know that, but if what you get isn't reasonable, then you won't get a
valid username back anyway. And that's all that matters, getting the right
username out. If it's a valid DN but not a valid user, then it's going to
fail anyway. So the syntax isn't the point of this.

> Now whether or not this can be done without the OpenSAML 1.1 format
> handlers is another question.  I rather doubt it, but I'll leave that
> open for the moment.

In the current code, it would require brute force rules running inside the
plugin based on the format. The abstraction layer would just be moved from
one library to another, which obviously serves no purpose. In 2.0, any SAML
object can have Validators attached, statically based on the type, or at
runtime dynamically, and they can enforce any rules you want.

There's a separation coming between the XML processing and the enforcement
of constraints, syntactic or otherwise, in other words.

I don't see any reason your general design won't work fine in 2.0 without
overriding the NameIdentifierImpl class, which is all I really wanted to
verify. Instead of checkValidity, you call validate, same difference.

-- Scott