Single SP, multiple applications

[Cantor, Scott]

> I’m working on implementing Shibboleth SSO for an existing application. It’s a
> multitenant SAAS application where each client organization accesses the
> application using a different subdomain name - client1.example.com,
> client2.example.com, etc. Rather than modify the core application, I’m
> experimenting with deploying a separate “bridge” that will perform the
> Shibboleth SP functions using the Apache module and then perform the
> signin to the application using an existing SSO mechanism.

That's generally a model the SP (and frankly SAML itself) is somewhat hostile to; it just isn't true federation and wasn't the design center around which it was constructed. So there's a fair bit of a mismatch than can lead to extra work with this implementation.

> After reading the Shibboleth docs (specifically
> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationO
> verride) I’m trying to decide whether it makes sense to set up a separate
> “application” for each client organization that we support or if this can be
> accomplished with a single application.  I have what appears to be a working
> setup with a single “application” but I guess I could use a sanity check.  In my
> Apache config I have multiple <Location> blocks, one for each client that we
> wish to support.  Within each <Location> block I’m overriding the default IdP.

Yes, that solves the discovery issue, which was something that used to require overrides, and is now fairly simple to do without that extra hassle.

But it doesn't solve a couple of issues:

- authorization / limiting of trust
- endpoint management

The former issue is simply that using one source of metadata at the top level, which is something the SP was meant to do, allows for any IdP to deliver an assertion to any ACS endpoint. That is, you have to be able to separate limiting trust from limiting access. The way we do that in higher ed is by using explicitly scoped, global identfiers for users that don't collide. That breaks down in a lot of simple B2B silos because companies tend to use simple identifiers like an employee ID, which aren't globally unique. So you typically end up needing application controls to limit the IdPs a silo will accept a user from.

The latter is simply that because you're "massively vhosting" your SP now has a set of SAML endpoints for every vhost, which means you will have hundreds of endpoints. That eventually will probably cause trouble, be it to a federation's management tools, or simply hitting a scaling boundary in the IdP.

The unfortunate solution to that is an entityID per customer/vhost, which is more concise, but means you end up having to define overrides after all, and it means that instead of a simple uniform SP presence for customers to enable in their IdP, every customer has unique information.

In a nutshell, this is where the Shibboleth SP design falls down vs. a traditional commercial gateway design of a single server handling traffic for everything, because they use a separate SSO protocol in between the gateway and your system so that the resources and the SAML endpoints don't need to share a vhost. That's the requirement the SP has by virtue of being colocated with the protected resources.

I hope that clarifies things; I think you have a handle on the issues here and that the above will probably make some sense.

-- Scott