IDP3 authn intercept question

[Cantor, Scott]

On 9/30/15, 2:19 PM, "users on behalf of O'Dowd, Josh" <users-bounces at shibboleth.net on behalf of Josh.O'Dowd at mso.umt.edu> wrote:
>
>We have the intercept deciding whether or not show the form, based on some logic which requires a return attribute from the bindAuthentication and the user entered password.

Then the problem is that you want the intercept to destroy the session, not just prevent a response.

By the time this is running, the session has already been preserved (including the AuthenticationResult). The context tree doesn't matter.

I think you really should look at hooking, or if necessary replacing, the login flow itself and prevent it from producing a successful result in the first place.

It might be possible to do it with the conditions flow that runs after the validation step, if there's something in the error/warning state of the results that could be mapped into an event.

Or it might be possible to get into the flow by adding a transition rule for "proceed" to the ValidateUsernamePassword state that goes to a custom state/subflow in conditions-flow.xml. I think that will supersede the proceed rule that's in the Password flow proper.

Either way, that's the better choice than trying to delete things after the fact. If it comes to it, I can probably just add a general "final" callout that could block any login flow from succeeding.

The problem here is that intercepts are meant to be usable whether or not authentication just took place or happened earlier.

-- Scott