Duo IdPv3.3 c14n null principal.

[Cantor, Scott]

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

> Not in the case where we hook them to a condition.  I am doing the same condition hooks for expired and reset that I am
> doing for expiring.  Those are being transitioned to sub-flows in the conditions.xml.  Under flows/authn/conditions/, I have
> expiring-password, expired-password, and reset-password directories for each sub-flow.  It is in these subflows that I have
> a registered Action bean that executes "manualc14n", as I showed in the code snippet.   Those sub-flows all have 2 end-
> states, either 'proceed', or 'SubjectCanonicalizationError'.

It's academic at this point, but prior to 3.3, the contract would have been to build authentication results, and populate only the Subject and a couple of other fields in the SubjectC14NContext. The one you should not populate under ordinary conditions is the principal name. Doing that essentially short circuits c14n.

Doing that in 3.2, I dunno what it would have done, I suspect the authn flow may have just not noticed and ran c14n anyway. With 3.3, it definitely has implications and will cause c14n to be skipped, which means essentially it's hardwired to act as though the "simple" c14n feature was used, possibly an acceptable result.

I don't know why I would have ever told you to set that field, but I doubt I understood what I was being asked.

> The setup I have described above was meant to do just that.  I am not hijacking any of the authentication flows in any
> way.

By copy the flow, I mean not use Password at all, copying it to something local and using that instead.

-- Scott