Intercept flows called even when in SSO session

[O'Dowd, Josh]

Thanks Scott,

> The post-authn intercepts definitely run regardless.

This is a post-authn sub-flow, but it depends on the returnAttrs from the bind authentication.

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

Yes.  I am looking for something, at subflow entry time the tells me this is/is not SSO reuse.  I can play do some context dissecting with debugging, if I need to.  I was just hoping you knew of something easy to point me to.

My best to your cat.
-Josh

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Friday, August 14, 2015 2:00 PM
To: Shib Users
Subject: Re: Intercept flows called even when in SSO session

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

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