Duo IdPv3.3 c14n null principal.

[Cantor, Scott]

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

I didn't know which ones applied, but that's the case I'm talking about. Handling the condition is fully supported (if, I think, a lot harder than just using the MFA feature is now) but manipulating the state of the context tree to make it look like the Validate bean succeeded essentially means assuming you know what the internals of that bean do, and that's implementation-dependent, at least to some degree. It's not exactly undocumented because most of it is just satisfying the contract that the login flow is documented to satisfy, but I'm not comfortable saying it's supported to do it that way.

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

That's more a Daniel question, but that was my thought.

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

Yes, and it probably assumes that there's enough coming back from ldaptive to satisfy the requirements of a "success" result anyway, and I don't know if that's true.

> I am not inclined to clone an entire native authn flow config and api to get
> this done.

Technically you could do it by just plugging in your own "back-end", which is really just one bean. That's described in the documentation now once I verified that in fact you could cleanly replace the validate step with that one bean. So it's not entirely crazy.

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

I have to say I have never heard of anybody allowing expired passwords. That seems to defeat the purpose of expiring them. I know as I user I certainly wouldn't bother to change mine if it just kept working.

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

Thank you,
-- Scott