Shibboleth Developers

["Tom Scavo" <>]

On 5/23/06, Scott Cantor 
<>
 wrote:
> > The ability to collapse the majority of SAMLNameIdentifier formats
> > into a single class/config option.  The only ones not covered are
> > transient and persistent, which are different beasts altogether.
>
> That's a Shibboleth function. It doesn't have anything to do with the SAML
> class hook that I can see.

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.

> > So are you suggesting that PrincipalNameIdentifierMapping could be
> > implemented in Shib 1.3 without using the hooks from OpenSAML 1.1?  I
> > don't doubt you, but I don't see how to do it, I'm afraid.
>
> There's nothing important in there that has anything to do with the OpenSAML
> classes. Take out the call to checkValidity. Done.

Ouch.  That totally defeats the purpose of this exercise.

> 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. ;-)

> My concern with this is just making sure that we're not losing any of this
> capability in 2.0. Which I don't have any reason to think, but that's why I
> asked about the connection.

Well, if you're not planning on implementing the format handler idea
in OpenSAML 2.0, then yeah, this is a terminal implementation.  Sorry,
I don't see how to do it any other way.

> The basic SAML class (old and new version) is perfectly able to handle any
> string based format. It just doesn't check the syntax.

But that's the whole point!  If the implementation doesn't bother to
check the syntax, then none of this makes any sense.

> Which I think is
> irrelevant because the regexp here is what constrains the patterns you'll
> get anyway, so if it's correct, the syntax will be, and if you were handed
> bad data, the reverse mapping would just fail.

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.

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.  Although it's possible to check the syntax of an
emailAddress (e.g.) with a one-string pattern, I wouldn't want to do
it, and I surely wouldn't want to depend on the deployer to get it
right.  See the emailAddress format handler to see how complicated
this is:

http://viewcvs.globus.org/viewcvs.cgi/gridshib/idp/src/org/opensaml/nameid/EmailAddressNameIdentifier.java

In the case of X509SubjectName, I claim it's not possible to check the
syntax with a regular expression.  Instead, the format handler uses
the X500Principal class:

http://viewcvs.globus.org/viewcvs.cgi/gridshib/idp/src/org/opensaml/nameid/X509SubjectNameNameIdentifier.java

So these are nontrivial implementations of checkValidity() we're
talking about here.

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.

Tom