Duo IdPv3.3 c14n null principal.

[Cantor, Scott]

On 12/28/16, 3:07 PM, "users on behalf of O'Dowd, Josh" <users-bounces at shibboleth.net on behalf of Josh.O'Dowd at mso.umt.edu> wrote:

>    I really do know that c14n isn't happening in the hooks.  I was under the impression that it was being built in the
> Password flow because by the time it reaches the condition subflows, I think I am seeing the presence of an
> AuthenticiationResult, populated with a Subject.  I'll check that again though...

You would in the case of a non-error event like that, because it's set up to be finishing successfully, it's just giving you a chance to either add something or short-circuit the result.

Before 3.3, the way it all worked was that the login flows built results and the master authn flow set up the SubjectCanonicalizationContext and performed that step.

In 3.3, every delivered login flow is now rewired to perform the c14n step itself before completing, and then for backward compatibility the master authn flow checks to see if it still needs to do that itself. The design documentation for writing login flows mentions this and covers the fact that it's part of the 3.3 contract to perform that step.

The reason for the change is, well, Duo basically (and everything else like it). Doing it back in the login flows lets one factor produce a usable result for other factors to consume, and c14n is often a precondition to really relying on the results fully. Some sites (e.g. mine) normalize about 3 different user inputs down to something in the directory to limit the names Duo sees. E.g. I can login with my employee ID but Duo still sees cantor.2. Pulling the remap back into the login flows accomodates that case within the MFA flow.

(That's all background, but that's why the regression occurs.)

-- Scott