using Shibboleth to authenticate for a multi-tenant application

[Cantor, Scott]

> My company has a multi-tenant SaaS app that requires three pieces of
> information to sign in a user:
> 
> *	company
> *	user name
> *	password

Right out of the gate you have to recognize that "company" is not a standardized notion, in LDAP, SAML, or anywhere. So that creates issues. There are some common assumptions that get made, such as that an IdP's entityID corresponds to one company, but that's not true. There's an N:N relationship there. So that's a challenge that most of these approaches just ignore.

Even if you ignore the 1 IdP:N company case, with real enterprise IdPs you still have the N:1 case because of universities with multiple campuses.

> User names need only be unique within a company.  In most scenarios, we'll
> be able to implicitly identify the company when the user comes to our
> service through a vanity subdomain.

That can be done, but it's also easy to screw up and leave attack surface. It also leads to problems with identifier scoping flaws like Microsoft's recent one. It's done all the time, but if you wanted me to bet money on it being done correctly, I wouldn't lay that bet.

At the very minimum, you need to bind those identifiers to issuing entityIDs if nothing else.

> What I wish to know better, however, is how well Shibboleth can be adapted
> to provide authentication support for a multi-tenant application like ours,
> where 3 pieces of data (company, user name, password) are required to
> authenticate the user.  We also need to support company-specific password
> policies.

Shibboleth doesn't address the non-federated case at all, unless you mean something broader like making your "local company" cases essentially federated by running an IdP for them. Which I would in fact advocate doing, but it's almost never how people do it, and they pay the price for that mistake by ending up with a mess of local + federated. That's the worst option from the application side of things and yet the most common.

In terms of using Shibboleth SPs with siloed applications, it works. Often not well, but it depends on how it's done, how trust is managed, whether the application is able to enforce the right rules so that the SP can be taken out of the loop as early as possible.

It is never going to be a perfect fit because the SP is designed explicitly to support one set of resources offered up to many IdPs. That's the point of federation. Silos are the antithesis of that.

> Has anyone had experience using Shibboleth in this manner?

Many people use it that way, and some of them do it well and some do it badly, but the biggest problem is the vanity domain thing, it is fundamentally at odds with a raft of assumptions in the SP's design, because the SAML endpoints it operates have to be part of those domains, unless you can use domain scope cookies, which obviously leads to other issues that have to be addressed in a siloed situation.

-- Scott