Principal Connectors

[Rod Widdowson]

> Regarding where the code should live, I anticipate it moving out of the
> resolver. The existing PrincipalConnectors already get used by the SAML 2
> SSO profile handler to reverse a NameID inside an AuthnRequest.
> 
[snip]
> 
> After thinking about it more I'm hard pressed to see any actual
> distinction between the PrincipalConnector concept in V2 and the name
> canonicalization idea we discussed in Columbus.
> 
> If you think of a SAML NameID as just one of many tech-specific forms of
> name (like a DN is another), you see that it's really one idea.

Absolutely.  My only worry when doing this was whether to complete the split of the principal connectors from the attribute resolver. We get very little from it, except that it has worked well for v2, which was reason enough for me.

But then I got to thinking this morning (and this is not fully fledged you understand) how about we flip it around 180:  Principal canonicalization becomes a (specialized, separate,) attribute resolution with the idea of producing but one String attribute.  We would have data connectors to go from LoginContext to Attribute, and encoders to produce the (unique) Principal.  That way we get (for free) database, LDAP, scriptlet, velocity &c &c, we might even want to do filtering.   

Of course we'd need to keep things clear config wise, and simple/fast in the usual case...

Just an idea for a Sunday morning, but it might have legs?