Separation of Tenants in Software Design

In the deployment of software, multi-tenant systems make sense for separating teams or different customers with different use cases. Ideally, a tenant is separated as if it is running on its own system and has all configuration options and network security options individually configured. 

On the other hand, complexity should still be manageable, to make sure errors can be analyzed quickly and new personnel is onboarded quickly. 

In this post, I want to explore some concepts and ideas, as well as best practices. First, let us look at common concepts and ideas. 

Generally, default patterns are useful for onboarding new features. Of course, each goal/software solution is unique and needs to be planned individually.

I am thankful for any comment or discussion. This is my current point of view, which might change in the future.

Databases

Most environments have a persistence in some sort of database. These could be a document, graph, relational, or other concept. 

Following separations are possible:

• All data in one scheme: tenant connection determined via references to the tenant. Cross-connection is easy.
• Own scheme for each tenant: every tenant access needs separate authentication. 

Additionally, there can be a management scheme, containing general information and references to the tenants, this can be a general database scheme or can be defined in the configuration.

Although the complexity is higher I would mostly choose the multi-scheme approach. The higher complexity of reaching other tenants' data from within the context is much harder. In this approach persisted data can even be physically separated.

Authentication

Authorization is one of the core security gateways. Generally, standardized and tested approaches should be used. The current state of the art would be OAuth2/OIDC, which is an open standard, integrated with a lot of frameworks, and security and best practices are available broadly.

Here are two concepts:

• One identity provider
• Separate identity providers

Identity Provider (IDP) could also be a REALM or App, depending on the wording.

Technology-wise it is easiest to have one provider. within the source code, only one IAM needs to be checked, and changes within the token information/structure need to be done for all Identity Providers. In the case of one identity provider, the tenant needs to be in the Token, to verify resource access. 

On the other hand, it is much harder to get a valid access token with escalated privileges from another identity provider. In this case for example, when logging in the login page forwards to the correct IDP, or the reference to the correct IDP is in the URL/FQDN.

Services

Looking at resource costs, the goal is to allocate as few resources as possible. So, most of the time it makes sense to share the service instances and check the tenant within.

For safer environments, it can make sense to deploy a separate service, which only gets access to the data of the connected tenant. In this case, only the services dealing with sensitive data should be scaled like this. Data then can be forwarded to the right service by the gateway. It makes sense when all services between the user call and the service handling the information are separate services, to ensure no access from other tenants.

Configuration

The challenge with configuration is, that it is often loaded with service start-up. One possibility is to not use the native configuration logic, and load all configurations from the tenant database/data when accessed. Another possibility is to have a configuration map loaded.

Some service-wide settings, like the port, TLS headers, or such parameters can only be configured per service, in this case, a multi-service approach should be verified, as described before.

Logging

Each tenant-specific logging must have the tenant reference in the metadata.

In a service-oriented environment, central logging should always be established for SIEM and general Audit overview. So the possibility of filtering all logs for a specific tenant exists.