NameID Encoders doubts from V2 to V3

[Lalith Jayaweera]

Thank Scott for the detailed explanation

Regarding first para, I don't intend to use the legacy feature basically it
is disabled, rather migrate across to the need of new V 3

Confusion I had was, documentation states those two types are deprecated
but I was not sure, for V 3.x do I have to use anything else instead.
That is, If I am not mistaken, not only It is deprecated in V 3.x also we
don't need to use any type at all in saml-nameid.xml for the nameID?


On Fri, Apr 21, 2017 at 12:45 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> > 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
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170421/c7bd20f1/attachment.html>