Intercept flows called even when in SSO session

[Cantor, Scott]

On 8/14/15, 3:51 PM, "users on behalf of O'Dowd, Josh" <users-bounces at shibboleth.net on behalf of Josh.O'Dowd at mso.umt.edu> wrote:

>It appears that our authn intercept sub-flow is being called even when the subject already has an SSO session, but is requesting a subsequent SP.

Are we talking about an intercept or an event handling subflow inside the Password flow? Your earlier issue was the latter...

The post-authn intercepts definitely run regardless.

>This is raising an issue with our intercept which relies on elements within the authentication
> context which appear are going to be missing in this scenario, the LDAP response, for one.

Right, but you can check for that and simply advance...?

> 
>I’m sure there are valid reasons why intercepts would need to be called when building an authentication response for an existing SSO session subject, but is there a clean way of bypassing this behavior, maybe a way with the intercept sub-flow, like a decision-state that we could use to just pass it through?

Well, it's your flow, you can certainly build in a decision-state.

If you wanted to disable your flow under some condition, you would wither code it explicitly within the flow to do so, or attach an activationCondition to your intercept's FlowDescriptor bean that you have to register in the list of flows, and have it perform a check, assuming it's something that would be known up front.

>I am wondering if there is something in the context tree that would tell us ‘this user already has an SSO session and we’re just building a response for the requestor’.

That being the trickier part, though. I don't have something I can point to off the top of my head, but I can look at it when I'm back from my cat's vet appt.

-- Scott