Event transition issue for IdP 3.3.1

[O'Dowd, Josh]

>  The problem is the end state. The security fix in 3.3.1 is that it no longer just auto-transitions. Your subflow is ending with ValidateUsernamePassword, and prior to the fix, that end state caused the calling flow to transition to that state. It no longer does that for you, if you want that to happen you would have to add a transition rule to the conditions flow itself inside the CallExpiringPassword state so that it handles that event and not just proceed.
, 
Agreed.  Thanks.

> I'm saying, use an interceptor after the fact.

What is nice about the conditional is that the LDAP bind response may/may not provide an account state code that maps into the condition flow(via shibboleth.authn.Password.ClassifiedMessageMap). Similar to password-expired, except the bind succeeds with expiring,  but fails with expired.

If I do an intercept( and I think you have actually provided an example config for this, conf/intercept/expiring-password-intercept-config.xml), the caveat is I will likely have to define password policy at the IdP with calendar-math, instead of utilizing the account-state indicator from the LDAP bind response(where we believe password policy should be applied)...  or can I access the bind response and the AccountState object within, from the interceptor flow?  I'll have to poke around for that option first.

Josh

________________________________________
From: users [users-bounces at shibboleth.net] on behalf of Cantor, Scott [cantor.2 at osu.edu]
Sent: Thursday, April 13, 2017 9:47 AM
To: Shib Users
Subject: RE: Event transition issue for IdP 3.3.1.

> I can't remember, but I may have done the re-validation in an attempt to
> trigger the c14n that occurs "naturally" at the end of the password-authn-
> flow.

But that's not going to be impacted by changing the password. I'm saying, use an interceptor after the fact.

> Well, I am pretty sure we tested that it was working in 3.3.0.  I will share the
> transition snippet from expiring-password-flow:
the 
The problem is the end state. The security fix in 3.3.1 is that it no longer just auto-transitions. Your subflow is ending with ValidateUsernamePassword, and prior to the fix, that end state caused the calling flow to transition to that state. It no longer does that for you, if you want that to happen you would have to add a transition rule to the conditions flow itself inside the CallExpiringPassword state so that it handles that event and not just proceed.

So it's doable, it's a bug in your original config that was taking advantage of a shortcut we had to remove.

-- Scott

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