Multi-Tenant Application

[Tyler Ashbaugh]

I have a multi-tenant application and I am using SimpleSAMLPHP as the SP and I would like 2 tenants to be able to use the same IDP but perhaps have different configuration (we are storing the saml config in a db table). The problem is when the IDP redirects to the SP, SimpleSAML uses the Issuer/IDP to look up the config, not the entity ID.

Any suggestions of how I can make this work?

[Jaime Perez Crespo]

Hi Tyler,

On 9 Mar 2018, at 23:29 PM, Tyler Ashbaugh <tr.as...@gmail.com> wrote:
> I have a multi-tenant application and I am using SimpleSAMLPHP as the SP and I would like 2 tenants to be able to use the same IDP but perhaps have different configuration (we are storing the saml config in a db table). The problem is when the IDP redirects to the SP, SimpleSAML uses the Issuer/IDP to look up the config, not the entity ID.

The issuer of a SAML assertion *is* the entity ID of the IdP.

I’m not sure what’s your problem here, but I’m guessing you have fixed configuration for your SP, meaning it can only be used for one of the tenants. If that’s the case, remember your configuration file is PHP code, so you can detect the tenant based on the environment (e.g. using the current domain) and load different configurations based on that.

—
Jaime Pérez
UNINETT / Feide

jaime...@uninett.no
jaime...@protonmail.com
9A08 EA20 E062 70B4 616B 43E3 562A FE3A 6293 62C2

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[Tyler Ashbaugh]

Hi Jaime,

Thanks so much for the suggestion. We've now managed to create a dynamic configuration file that can load different database configurations.

We're now trying to determine the best way to check the environment.

We got a version working that checks the URI (via REQUEST_URI) as there's information specific to each tenant. The issue with this is that to make this work on the hop back from the IdP to the SP we basically have to enforce a specific entityID per tenant so we can determine which tenant is authenticating.

The other option we're thinking of is to put tenant specific information in the session (by using the kvstore table) and get this at the top of the configuration file. Do you think this is a good idea?

[Peter Schober]

* Tyler Ashbaugh <tr.as...@gmail.com> [2018-03-15 19:43]:

> We got a version working that checks the URI (via REQUEST_URI) as
> there's information specific to each tenant. The issue with this is
> that to make this work on the hop back from the IdP to the SP we
> basically have to enforce a specific entityID per tenant so we can
> determine which tenant is authenticating.

Not sure what you're trying to do but one SP can interop with as many
IDPs as you want, without any special configuration, and without
making the SP specific to each IDP. I.e., not doing anything for
multi-tenancy will give you this out of the box.
(Your service is your service, it should not pretent do be something
else depending on who's asking.)

You can still give different access to different people (this is
simply access control), but basing on entityID is generally not a good
idea. Relying on attributes is both simpler and more flexible.

Also there's nothing extra you'd need to do to "determine which tenant
is authenticating", you simply use the PHP API SimpleSAMLphp gives you
to pull out the entitID of the IDP. The docs cover the API.
-peter

[Tyler Ashbaugh]

@Peter, consider the following:

We have a single SP, but three customers lets say Customer A, Customer B, and Customer C.

Customer A uses IDP 1

Customer B uses IDP 2

Customer C uses IDP 1 as well but their metadata for IDP 1 is different than Customer A's metadata

We then need multiple entries in the saml20_idp_remote file representing IDP 1 and we need our SP to respond appropriately depending on if Customer A or Customer C is authenticating.

Does that make it a little bit more clear?

[Peter Schober]

* Tyler Ashbaugh <tr.as...@gmail.com> [2018-03-15 20:39]:

> We have a single SP, but three customers lets say Customer A, Customer B,
> and Customer C.
> Customer A uses IDP 1
> Customer B uses IDP 2
> Customer C uses IDP 1 as well but their metadata for IDP 1 is different
> than Customer A's metadata

If IDP1's entityID is always has the same but something else within
that metadata is required to differ that's just broken by design.
It may still be possible to create a unified EntityDescriptor for that
IDP, e.g. one that has all the endpoints and all the certificates
used. What is it that needs to be different?

If the entityID is not in fact identical in cases one and three then
you just have 3 different IDPs and all is as it should be.

-peter

[Tyler Ashbaugh]

Fair enough, but the crux of the issue here, which I don't think I really explained is that we want to allow each customer the ability to upload their own metadata as a self serve operation. The trouble with this scenario is if Customer C uploads metadata that they modified but has the same entity id as Customer A then it breaks SSO for both Customer A and Customer C. We're already doing some metadata validation on what they upload to prevent malformed metadata but it wouldn't stop someone from let's say changing the url for the logout service or something. This is why we wanted some extra key outside of just the entity id to tie metadata to the customer who is using it. 

[Peter Schober]

* Tyler Ashbaugh <tr.as...@gmail.com> [2018-03-15 21:29]:

> Fair enough, but the crux of the issue here, which I don't think I really
> explained is that we want to allow each customer the ability to upload
> their own metadata as a self serve operation. The trouble with this
> scenario is if Customer C uploads metadata that they modified but has the
> same entity id as Customer A then it breaks SSO for both Customer A and
> Customer C. We're already doing some metadata validation on what they
> upload to prevent malformed metadata but it wouldn't stop someone from
> let's say changing the url for the logout service or something. This is why
> we wanted some extra key outside of just the entity id to tie metadata to
> the customer who is using it.

I have nothing to offer here (as in: What parts to hack to make all
this brokenness manageable).

Out of curiosity: What IDP is that that gives different "customers"
differing entity but with the same entityID, and expects all the SPs
in the world (they interact with) to hack around their brokenness?
-peter

[Peter Schober]

* Peter Schober <peter....@univie.ac.at> [2018-03-15 21:34]:

> Out of curiosity: What IDP is that that gives different "customers"
> differing entity but with the same entityID, and expects all the SPs
> in the world (they interact with) to hack around their brokenness?

Should have been "differing metadata but with the same entityID", of
course.
-peter