Subject Canonicalization

[Rod Widdowson]

> >The configuration around selection of which c14n action is to be called
> >for
> >normalization of NameIDs to be called is tbd.  Initially we may well
> >decide
> >to hard wire it, longer term there are other strategies available to us,
> >starting with specifying the class as a property, to the full
complexities
> >used for authentication.
> 
> I favor doing something more or less the same as authentication so it's
> consistent.

You mean using an XXXFlowDescriptor (any suggestion for a name?) and
subflows which contain an implicit redirect?  I'll need to get my mind
around exactly how that works, particularly the magical <subflow-state
subflow="EL"> statement.  

> What I was thinking is maybe we could build a c14n flow that internally
> decides what to do based on the same config file as the resolver, for
> compatibility, but isn't really part of the resolver. And we would
> deprecate that approach, and provide a more direct config path.

I hear you and support the need to deprecate the <PrincipalConnectors>, but
I'm not sure how to achieve this without with writing an entirely different
stack of parsers for attribute-resolver.xml (which I'm not sure is
possible).  Or we could duplicate the parsing, but I'm worried about the
cost of setting up Database & LDAP connections.  This is consideration for
Attribute mapping too (which is also derived from that file).

Thinking on this overnight: can we not define an Interface which is
effectively a Function<C14NCtx, String>.  Then AttributeResolverImpl can
implement it, but so can other things, including a new WhateverWeWrite
class.

We would then end up with two C14NFlows defined using the same Action
Implementation, one takes an injected
ServiceableComponent<AttributeResolverImpl>, the other takes an injected
ServiceableComponent< WhateverWeWrite >.  The former would only be usable
for SAML C14N, but the other could be used for anything; hence the Action
could be used for C14N in AuthN, but because it goes via the
ServiceableComponent structure we can keep the configuration in a separate,
reloadable file.

At this stage however my mind begins to melt slightly under the
configuration options.  I'm not saying this is bad, but it requires thought
and will need careful documentation (or at least separation of user and
system configuration).

> So far that hasn't been needed because our core code always generates a
> UsernamePrincipal and that can be run through various transforms, but we
> can take a look at things.

I'd spotted the transforms, but not internalized them (probably because I am
blind about seeing regexp (http://xkcd.com/1313/)
 
> I think it would be best to just verify that if one wanted to do the work,
> one could create a flow that invokes the resolver, but I don't think we
> need necessarily make it a special resolver.

I'll do that.