1

Our team is currently building out an application built with microservices. This application will handle many tenants (organizations) with a database per tenant design. Authentication is handled by Auth0. A user logins in on an SPA and all requests are sent into an API gateway where the JWT is authenticated.

Based on my research to handle database per tenant we should have a tenant catalog database with information about that tenant including their connection string.

What are best practices for handling this connection string (and tenant catalog). Specifically, where should the work to retrieve a connection string be done (gateway, separate service, etc.)?

The tenant will be resolved in the API Gateway as the users JWT will contain a claim for the tenant identifier.

  • 1
    Are you planning to deploy MS per tenant too? (So tenants can scale up/out according to their needs) or is going to be only one MS infrastructure covering up the service for everybody? Note that the first, only takes deploying MS with different configurations,w hile the second ask you for a new MS to provide others with connectivity. Or a dependency to make this possible – Laiv Sep 29 at 15:54
0

I would advise simply having a single DB connection in the api and deploy an instant per tenant.

The goal of separating tenant databases is to provide sureity of data segregation. But having a single API which routinely connects to all the databases undermines this goal.

Separating the APIs carries that segregation through the layers, allowing defence in depth via IP filtering on a firewall, alternate authentication databases etc

A similar argument applies to anywhere where you take an input variable and decide which database you are connecting to. SO no doing it on an API gateway or router or dns either! you need to ensure that a single mistake at that point can't allow access to the incorrect db.

eg.

I browse to ewanc0rp.multitenant.com by accident instead of ewancorp

First off, perhaps I should be blocked because my IP address isn't whitelisted. But lets say its open to the internet and I am presented with a login prompt.

It should be impossible for me to login, my user simply shouldn't exist on anything ewanc0rp can access.

But lets say there is a shared auth and I'm let in.

The code should check that I have a claim saying I belong to ewanc0rp and fail because I have a ewancorp claim instead.

That's three things that have to go wrong before I can access the data. any single mistake will cause errors but not expose data.

The danger of a 'connect to db based on a variable' is that its only a single misconfiguration which is required to expose the wrong data. Sometimes that is acceptable, but if it is you can probably move to a multi tenant database.

| improve this answer | |
  • In what cases does it makes sense to have database-per-tenant architecture. It is very costly and an overhead. Are there any real life situations where such things are mandated even for a Saas application? – Sahil Gupta Sep 29 at 18:42
  • yes, sometimes you legally or contractually have to seperate data – Ewan Sep 29 at 20:01
  • @SahilGupta There are some solutions that can reduce the price and overhead, such as Azure elastic pools. Not affiliated to it, but the only one that I've used so far. – Ivo Merchiers Sep 30 at 9:30
  • thank you so much @IvoMerchiers for your input. – Sahil Gupta Sep 30 at 10:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.