Duo IdPv3.3 c14n null principal.

[O'Dowd, Josh]

> The latter two are "failure" cases, they pass control back to the view step in the flow.

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'.

> I think I would tell anybody playing that kind of game to copy the flows and do everything themselves, to avoid being affected by changes.

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

Josh

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Wednesday, December 28, 2016 1:09 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Duo IdPv3.3 c14n null principal.

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

> Sorry, you are right, I am talking about conditions.  We have 3 which can be triggered by our password policies:
>  expiring-password, expired-password, and reset-password.

Yes, I deduced that. The latter two are "failure" cases, they pass control back to the view step in the flow. But the first one triggers a transition to "proceed". That state ends the password flow successfully, and that used to be the same result you got if there was no condition fired. Now it's not, the normal outcome is to set up for subject c14n and pass control into that step before completing. So it's a regression in 3.3 I didn't catch.

It's actually a breaking change I didn't mean to make, because fixing this requires a user file change. That would have made it an invalid change, but having shipped it, and given how few people it will impact, it's water under the bridge, just has to be patched and documented now.

> A while back, in v3.2, I had discussed with you, the issue of how to 
> session the authenticated user when the ldap response is 
> password_expired.  You gave me instruction at that time to manually create a SubjectCanonicaliztionContext and populate it with a subject and a principal.

I don't think I would have suggested you do that *inside a login flow*, given how 3.2 worked. I think I would tell anybody playing that kind of game to copy the flows and do everything themselves, to avoid being affected by changes.

>  You gave me a code example to follow, as well.  We have been rolling 
> with that for the past year.  What I am describing now as 'manual c14n' is a function, based on your prior direction,  that is doing the following:

Yes, that's essentially manually producing a result that would match what the "simple" c14n flow does. But I don't know why you'd have had to do all that, and I'm not clear on where you're doing it.

> We are getting the NPE because the duo signRequest function does a c14n.getPrincipalName call.

There's a Function that it defaults to using that does that call so it can piggy back by default on other login flows, all of which now *do* subject c14n explicitly and produce that outcome. The expiring-password condition breaks that assumption, that's the bug. 

>I think I already verified that the subject property was non-null, but I will recheck that.

The c14n context isn't there, actually, I suspect.

>If that is true, it doesn't add up with your statement that c14n isn't happening at all in the conditions hooks.

I would be surprised to find that was the case.

-- Scott
 

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net