Duo IdPv3.3 c14n null principal.

[O'Dowd, Josh]

> No, the stuff you're doing to fool it into turning a failure into success is what's implementation specific. That is not a supported feature.

Thanks.  The 'expired' error is the only one that comes with a failure result because the bind authentication fails.  I have verified that the 'reset' and 'expiring' are success results, leaving the expired scenario as my only trouble area.

We are using BindSearchAuthenticator.  I am going to check into whether ldaptive has any options for search results with expired passwords, that translate to a SUCCESS result with warning/error code rather than failure result.  That idea is based on a loose assumption that the origin of the resultCode is an ldaptive function.  I don't expect to find such an option, but at least I'll have tried.

For the IdP, I am not sure there is a viable "new feature" to be requested here since it would be asking the IdP to ignore or give exception to a failure result, based on configurable allowable reason codes.  Thus, the EXPIRED_PASSWORD, if configured, would be treated as a SUCCESS instead of a FAILURE(which I assume would fire c14n), with a condition to be handled by the condition-flow, similar to 'reset' and 'expiring'.

I am not inclined to clone an entire native authn flow config and api to get this done.  I would rather find a solution within the configurable bounds of the IdP, or convince the powers that be, here at UM, that our process for expired passwords needs to change, however inconvenient it becomes for the user.

Thanks again for your time.  My congratulations to you and the Shibboleth team on an outstanding software.

Sincerely, 

Josh O'Dowd

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Thursday, December 29, 2016 9:03 AM
To: Shib Users <users at shibboleth.net>
Subject: RE: Duo IdPv3.3 c14n null principal.

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

No, the stuff you're doing to fool it into turning a failure into success is what's implementation specific. That is not a supported feature.

-- Scott

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