Intermittent "None of the configured SessionInitiators handled the request"

[Wessel, Keith]

Maybe we missed something when we tested this without the handler several months ago, but our experience was that a user who logged into application A that used one IdP then logged into application B that used a different IdP was never sent to the other IdP. They already had an SP session. Thus, the SP saw no need to send to the IdP to authenticate.

If you believe that the default handler location should be able to juggle a scenario like this where a user can be logged into two different applications at different paths on the same virtual host, each fronted by a different IdP, we can definitely try it again.

Keith

-----Original Message-----
From: Cantor, Scott <cantor.2 at osu.edu> 
Sent: Friday, January 27, 2023 3:39 PM
To: Shib Users <users at shibboleth.net>
Cc: Wessel, Keith <kwessel at illinois.edu>
Subject: Re: Intermittent "None of the configured SessionInitiators handled the request"

> One question: you said we don’t' need an application override for 
> this. I know we don't need it to override the IdP entity ID, but if we 
> have multiple paths on the same host using different IdPs, they need different handler URLs on the SP.

Why do you need that though?

> How does one configure that without overriding the <Sessions> element?

You can't, but why do you need to do that?

If they're just separate applications, then you can just carve up the tree and stick in require rules that block access based on the IdP, right?

If they're separate IdPs, it doesn't seem plausible that people would be moving between the apps by design since presumably they're only in one IdP or the other.

-- Scott