XMLObject-based NameID encoders

[Cantor, Scott]

Sending to dev, just so it's visible...

On 1/29/14, 5:39 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>Makes sense.  I'd like to review what you've done so I understand what the
>code is up to if I have any questions I'll ask but then I'll scrub them

That's easy to summarize. So in a nushell:

The new core interface is NameIdentifierGenerator, and some subclasses to
that live in OpenSAML to facilitate implementations.

The two actual sets of plugins are in idp-saml-impl and are:

Default
Legacy

The Default pair work by configuring Format, various NameQualifier
options, and a list of attribute Ids, and it pulls the first compatible
value from the attribute list. Compatible means String, Scoped, or
NameIdentifier/NameID as required. For now I hardwired Scoped to construct
value at scope but probably should have an option for the delimiter.

So that supports any of the AttributeDefinitions people use today,
including the old XMLObject ones that were used to generate the
eduPersonTargetedId attribute syntax. So you don't need a separate
String-based definition and an encoder to get a persistent NameID.

The Legacy pair are used as a catch-all case and aren't locked to a single
Format, but given the Format to try and generate, they walk the
AttributeContext looking for a NameIdentifierAttributeEncoder for that
Format, and return the first one they successfully generate. That should
do essentially what the V2 code did, but we need to test with legacy
configs.

The actual Format precedence is controlled by a separate Strategy function
injected into the AddNameID actions, and the default one combines the
ProfileConfig's nameIdPrecedence setting with SP metadata to derive a list
to try. The exception is the SAML 2 NameIDPolicy case, which I haven't
implemented yet, but that just restricts the list to 1 and has to error
out if unsatisfied.

This is all configured with a map of Formats to lists of generator
plugins, and then the Legacy plugin is injected directly into the Add
actions as a fallback. Which could be turned on and off if we wanted some
kind of overall "disable compatibility" switch.

-- Scott