Duo IdPv3.3 c14n null principal.

[O'Dowd, Josh]

Sorry Scott, I need to revisit this with you, briefly, for some clarification...

> The bigger issue is that what you're doing is depending on internals of the login flow and there are no guarantees that won't change.

Are you saying that the 'conditions' functionality that is tied to the shibboleth.authn.Password.ClassifiedMessageMap may be phased out at some point?  That really is the only reliance that we have on the internals of the Password login flow, by matching keys from the map to transitions in the conditions-flow.xml.

Thanks.

Josh

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

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

>    You didn't tell me to set the principalName field on the 
> SubjectC14NContext.  I added that line to the older function to fix the NPE that duo is throwing when It calls SubjectC14NContext.getPrincipalName.

Ok. If you do that, you would be working around the regression *and* hardwiring it to behave as if c14n happened using the "simple" method with no transforms. If that's acceptable, then it's ok, but it should be adjusted to use the fix once it's available and then it will do the same thing functionally.

The bigger issue is that what you're doing is depending on internals of the login flow and there are no guarantees that won't change.

>    I think we just need some advice on how to implement our policy 
> where expired, expiring, or reset password conditions occur.  Again, 
> we just want to sub-flow these so that we can get password renewed, and then send user on their way to their requested service.

There is no supported way to do that. If you do it, you should clone the flow and own it, top to bottom, and that has to include copying a ton of implementation classes. Anything else is subject to change and breakage. That's just how it is. So my original suggestion is probably as good as it gets, since either way it's fragile, and at least it's less work.

What you would need doesn't exist, essentially a supported API to make the system do what you need it to while abstracting the internals that happen to fit the current implementation.

You need to file a bug on the expiring-password condition regression, and if you copy that eventual commit, it will obviate the need to keep setting the principal name. Separately, you should, I guess file a RFE for the feature you're asking about. That's just not a current feature of the system.

-- Scott


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