Is it possible for an IdP to service multiple SPs without SSO between SPs?

Cantor, Scott cantor.2 at osu.edu
Tue Aug 16 20:38:49 EDT 2016


On 8/16/16, 8:30 PM, "users on behalf of John Dennis" <users-bounces at shibboleth.net on behalf of jdennis at redhat.com> wrote:

>    Just out of curiosity, to prevent App1 and App2 on SP1 from sharing an 
>    authentication session wouldn't it be more appropriate to define App1 
>    and App2 as their own unique SP? If not why?

I was assuming they were separate SPs. That doesn't get you anything unless you attach policy of some kind to them though. If they're not separate SPs, then the only way to do this is to get them to issue requests with the required policy (i.e. AuthnContext) in them on the fly.

I also noted while I was poking into this that I have some bugs I've introduced into some of these mechanisms with the changes I made for MFA support. It's very complicated using the system to try and limit the login flows you can use, but allow login flows to run other login flows. It's getting very messy in there.

The rule of thumb really is, use the supportedPrincipals feature to enumerate what your login flows support, and drive things with AuthnContextClassRef and things will always work properly because that's deeply embedded in the system's design.

The lower-level features work to some degree but they're very brittle.

Another mindset with 3.3 is, use the MFA flow to drive all of your business rules and you can pretty much get exactly the behavior you want in every case with enough scripting.

-- Scott




More information about the users mailing list