A multi-tenant architecture is when a single instance of a service or application caters to multiple tenants, such as organizations, customers, or subsidiaries. A multi-tenant approach involves segmenting data and components, the extent of which is dictated by the service provider's needs, the type of data, and regulatory compliance requirements.

Although any organization may need to support multi-tenancy, it is especially a common requirement for managed services, also known as Software-as-a-Service (SaaS). A SaaS application offers its product to many different customers through a single service. But what if customer A can access customer B's data? Making sure that data cannot flow between the different customers is critical. The data schema is often designed with a tenant ID to accommodate the control of segregating tenants. When authorizing access to business resources, the tenant ID can be used and matched with a tenant ID in the access token used to request access.

Another scenario where multi-tenancy comes into play is within large organizations with multiple subsidiaries. For example, these may be different Lines Of Business (LOBs) or subsidiaries that stem from mergers and acquisitions. In these cases, there might be segregation already in place for some information but not all. The organization might wish to keep parts of the service or application separate but desire other components to be used globally across the organization.

The Importance of Access Control

There are various ways to separate data as needed. In any case, there is a need to apply some level of access control to ensure that users or groups of users don't have access to data they shouldn't have access to. With this in mind, a token-based architecture fits well. Tokens are used to control access to applications, services, and the data these services use. In a multi-tenant environment, tokens are issued with different scopes and claims for specific tenants. This ensures they provide access only to the correct information.

Separation of Identities

To achieve this level of segregation, organizations must introduce user, group, and role management. Users must be somehow associated with a given tenant, which can be handled in many ways but requires robust user management. This could become complex in a scenario with multiple identity sources. This is very common in the previously mentioned company acquisition use case, where each acquired organization has its own separate identity store. In these cases, having a flexible, standardized, and centralized service to handle user management is key.

Part of the user information will end up being claims data and is naturally segregated as part of segregating the user store. However, additional claims data could be associated with the user that needs to be obtained from other claims sources. The IAM system must leverage different data sources, based on the tenant, to issue tokens with claims data added to the token.

{
	"sub": "d160e26d96888f1cac5b5ba8191df77d4053101551d17",
	"purpose": "access_token",
	"iss": "https://idsvr.example.com/oauth/v2/oauth-anonymous",
	"active": true,
	"phoneNumber": "5551231234",
	"client_id": "client-one",
	"aud": "client-one",
	"nbf": 1677797957,
	"scope": "records transactions",
	"tenant_id": "9824987",
	"exp": 1677798257,
	"iat": 1677797957
}

JWT example

When an application is processing an authentication/authorization flow, a session is established with the authorization server. The session typically persists in some data store by the authorization server. Depending on the level of isolation needed between the tenants, there could be a need for the session store to also be segregated. The authorization server issues tokens and must keep track of them. Similar to the sessions, the tokens are also typically persisted in a data store, and there could be requirements for maintaining separation between the tenants.

Last but not least, the authorization server probably maintains different levels of log information. These should not contain personally identifiable information (PII), but the log data might include tenant-specific details that should not be accessible across tenants.

There are a couple of different approaches to handling IAM segregation for tenants. Different scenarios will require varying degrees of isolation, spanning from total isolation to having certain components and data shared across tenants.

The Concept of Full Isolation

Conceptually this is easy to understand — all IAM components and data are fully segregated between tenants. There is no overlap where tokens, sessions, claims data, or user data are stored and handled by the system. Both the token issuance and authentication service are unique to the tenant. Endpoints that handle, for example, authorization, token, introspection, or user info, are separate and unique to the tenant. They are also authenticated and secured only for that specific tenant.

Full isolation is simple in concept but obviously puts more burden on managing the system as a whole since each tenant is fully isolated and separate. This is on the extreme end of the spectrum of how much segregation may be required. Nonetheless, from Curity's perspective, such isolation can be easily solved by leveraging configuration profiles. A single instance of the Curity Identity Server can be configured to use separate token service profiles for each tenant with individual configurations. It's even possible to implement with a single configuration — this can leverage parameters (variables) to instantiate a fully unique configuration for each tenant but leaving only one configuration to manage.

Tenant Profiles

Isolated Database

The Curity Identity Server allows for the configuration of a multi-zone data source. This approach could leverage the concept of zones, where each zone is mapped to a tenant. The tenants can share a token service and a common profile and endpoints. The configuration of a zone would equate to a tenant ID, and the multi-zone data source would map to the actual underlying data source for the given tenant based on the tenant ID and segregate token information accordingly.

The setup would be simplified as it removes the need for separate profiles and endpoints for each tenant, especially when the number of tenants grows large. It does, however, allow for each tenant's tokens to be stored in a fully isolated data source.

Shared Components

A more common approach, particularly in scenarios with a larger set of tenants, is to have some components shared while still applying a level of segregation of components and data. In these cases, there is some overlap in components like authorization and token endpoints, token store, and other areas.

In such a setup, the token service can be shared. With that, tokens for different tenants are stored in the same data source. A significant amount of control around how a token is issued is still possible to configure within the client settings in the Curity Identity Server. Properties can be used that are consumed by a token procedure to direct specific behavior needed by a given tenant. It is also possible to configure unique claims mappers for each client to control how claims data is populated in the issued token. A unique tenant ID claim is still issued in the token to authorize access to resources later on. 

In this approach, even though a token service is shared across multiple tenants, segregation can still be achieved by configuring separate OAuth clients. Organizations can configure elements differently for each tenant, such as the user authenticators and the look and feel of the login screen.

Tenant Clients

Conclusion

The Curity Identity Server provides flexible and powerful configuration options to help implement either of these multi-tenancy strategies or even a hybrid approach. The flexibility in supporting multiple data sources and profiles and providing full control over the procedure that issues the tokens makes it possible to handle a wide range of multi-tenancy options. Authentication options can be separated on their own, and with the power of authentication actions, the user's identity can be built-up in a workflow-like manner to create a unique approach for the identity of each tenant.