Running the Curity Identity Server in a Multi-Tenant Architecture

The Curity Identity Server was built with multi-tenancy in mind from the very start. Everything from configuration through CLI, RESTCONF API and Admin UI is designed to handle complex and advanced multi-tenant scenarios. This also means that multi-tenancy is supported natively within the product without any need for custom coding, it will just work through configuration.

This article will review the different components within the Curity Identity Server and how they related to a multi-tenant architecture.

Separate Services

Separation of concerns is one of the major reasons that the Curity Identity Server separates its functionalities for authentication, token issuance and user management. It follows the concept of "do one thing and do it well". Authenticating users and issuing tokens are separate tasks and should as such be handled by different services. The Curity Identity Server can handle any number of Authentication-, Token- and User Management services that are deployed in the same cluster to handle multi-tenancy at scale.

This also means that each service can be configured and run separately from other services. It is absolutely possible to deploy several different services on the same node but when it comes to larger scale environments and environments with strict High Availability requirements the services can be separated and clustered for scalability.

With this in mind it is possible to create unique services in a way that each tenant has for example their own separate Authentication- and Token Services. These services are then deployed to a single node or cluster of nodes, depending on scale and performance needs. It would on the other hand also be possible to deploy several separate tenant services to one node or cluster although they would run completely independent from each other.

Services, Profiles and Service Roles

Profiles are a way of segregating deployment configurations. A Service that is created with a given configuration such as capabilities, signing keys, endpoints, etc. is assigned to a Profile. A Profile creates a "swimlane" of Services and is assigned to one or more Service Roles.

A Service Role is assigned to each node in the deployment (cluster). This allows templates to be defined for specifically configured systems and can be unique to each tenant.

Shared or Fully Isolated

The Curity Identity Server leverages several underlying components for different configurations. One such example is a Data source, i.e. a database or ldap or similar used to store data. This could be credentials information used by an instance of an authentication service but could also be where a token service store token information when issuing tokens.

Even if a database was shared but separate profiles are used for each tenant the Curity Identity Server will pre-append every entry so that no cross-reference would happen between cookies, tokens, etc.

Different services can share different components in the configuration but could also use their own isolated ones. This depends heavily on the requirements of the environment as it relates to isolation between different tenants.

In addition to Data Sources it is also possible to configure different encryption components that are used by different services and thereby also different tenants. Separate signing keys and certificates used by the deployment allows for further segregation and isolation of each tenants environment.

A last example is the configuration of endpoints. For all 3 types of services (authentication ,token and user management) it is possible to define unique paths in the endpoints. This also fully segregates each tenants environment from each other.

Configuration

All of this can naturally be configured in the Admin UI. However in large scale multi-tenant environments that is not a practical approach. As noted in the introduction, the Curity Identity Server was built with multi-tenancy in mind from the very first version. Both the CLI and the exposed RESTCONF API have capabilities to fully automate the deployment and configuration of all aspects in a multi-tenant architecture. Onboarding a new tenant would be very quick and easy by leveraging ready made configuration templates or scripts that can be executed through the CLI or RESTCONF API.

Detailed access policies can be configured within each profile to control access down to individual settings within a profile. The access policies applies to any configuration method (Admin UI, RESTCONF API or CLI) ensuring that one tenant (or an internal operator working on behalf of a tenant) cannot modify another tenant's configuration.

Summary

The Curity Identity Server has very flexible capabilities to achieve a multi-tenant architecture. Services can be configured to use separate underlying components such as databases, encryption keys, etc. Services are grouped in the Profiles that can be deployed to nodes in a cluster. Profiles can be leveraged to segregate and isolate each tenants configuration.