NameID Encoders doubts from V2 to V3

[Cantor, Scott]

> However it is not clear to be what is the new way and how to encode it in V3,
> does this mean, if the previous V2 encoding is SAML2StringNameID (as an
> e.g.) and we can ignore this in V3 and don't need to do anything with respect
> to NameID encoding?

If you mean will it still work, yes, there's a property that's enabled by default on upgrades that enables "legacy" use of the resolver to generate NameIDs. If you mean whether the IdP will ignore the deprecated encoders entirely, it will if that legacy property is not enabled, which is the case on fresh non-upgrade installs. The properties are in saml-nameid.properties and are marked pretty explicitly.

> Also if I am not mistaken with the new approach from below V2 resolver
> definition as an example, and in new V3, below will split into two, that is
> resolver will still continue to have this attribute with encoding
> enc:SAML2String but only higligthted SAML2StringNameID will be moved to
> saml-nameid.xml obviously without SAML2StringNameID

In effect, yes. They are separate functions. They always were, we just overloaded it all syntactically and that was ultimately more confusing in the end.

And to be clear, NameIDs suck for all sorts of reasons. They shouldn't be used. When you have to use them, you grin and bear it. There is a reason they are painful to use, they are not how Shibooleth is meant to work, and they will continue to be second-class citizens. Always ask the vendor to use an Attribute.

> Please confirm is that the correct understanding, if so, kind of double work in
> two files obviously with clarity

It's not double the work, it's just moving a step from one place to another, and adding clarity, as well as a bunch of additional features.

-- Scott