shibboleth.c14n.attribute.PrincipalNameLookupStrategy bean

[Cantor, Scott]

On 2/15/17, 8:35 PM, "users on behalf of Michael A Grady" <users-bounces at shibboleth.net on behalf of mgrady at unicon.net> wrote:

> Yes, I worked that out when working with a client, who also was using it successfully, I had to account for the fact that one
> ended up going thru the resolver multiple times -- for password, for Duo, for the actual standard resolution step, and
> various of those values it was depending on did or did not have values during some of those passes. Great that nothing
> that complex is needed now, and can easily be done somewhere else.

I might have been unable to follow it because of the Duo-does-it-again case, but the comments didn't line up with what the actual internals look like with regard to SubjectContext being set or not.

In any case, key point: my Duo flow does *not* invoke subject c14n, it bypasses it as a no-op (in fact in essentially the same way Unicon's sort of did). But all that is now defined/documented/supported/explicit, which was a major gap before.

Every login flow is expected to perform c14n, and if the appropriate result is not present, the authn flow does it as a backward compatibility nod. What any given flow actually does internally to perform it is up to that flow (i.e., Duo knows it needs to do nothing).

Much simpler while also being more flexible and avoiding those kinds of re-entrancy traps.

-- Scott