Imagine you are a service provider for computing infrastructure catering to either market customers or internal organization units. Your customers require a certain degree of data isolation and autonomy.

Two main architectures are available to provide the desired level of autonomy and isolation:

• Multiple Instances
• Multiple Tenants

With the former, you would deploy multiple instances of the same software for each customer, whereas with the latter, you would use only one instance that logically separates the customers.

As a conventional managed service provider, the preferred approach for deploying Identity Management solutions is multi-instances. Your customers are assigned their own instance of Microsoft Active Directory Domain Services. However, to adopt a modern cloud-based service approach, you need to consider a more scalable concept such as multitenancy. Multitenancy allows for better scaling and is increasingly associated with cloud-based solutions.

A tenant represents an institution, which could be a company, government agency or internal organizational unit. This representation brings together the users, workloads etc. of the said institution and provides them with a particular share of a central Identity Management solution.

Conceptional Considerations

With a single central identity management system, it is logical to assume that there is only one database, which is probably spread over multiple instances in a database management system. At this point, without delving into the underlying technology, it is necessary to store a distinguishing feature within the database to separate the different clients and tenants. Depending on the technology chosen, this could be a portion of a hierarchy or some attached information to the stored data, enabling separation during querying.

Implementation Choices

Typically, there are two widely used approaches to implementing a central Identity Management (IdM) solution that can handle multiple tenants.

The first method involves using a relational database with a schema that requires a tenant-ID attribute to distinguish between tenants. This approach is suitable for small IdM implementations where there is a limited amount of information to be accessed. For instance, if you deploy a Software-as-a-Service (SaaS) application solely for identity authentication and role-based access, then this approach works very well.

However, if you offer computing infrastructure, you must interact with legacy protocols in addition to providing Domain Name System (DNS), among other things. Consequently, directory services can be a viable alternative as they offer the necessary hierarchy to identify users and workloads. We will elaborate on this solution in greater detail in the following sections.

Tenant Structures in Directory Services

Common directory services implement the Lightweight Directory Access Protocol version 3 (LDAPv3) and support attributes and classes from the X.500 specification. This serves as the foundation for the forthcoming elaboration. We will examine the identification of tenants and the significance of the underlying structure.

Tenant Identification

Generally, a directory service will have an upper base DN (Distinguished Name) which serves as the starting point for all search operations and contains the underlying information. The Root DSE can typically manage multiple base DNs referred to as Naming Contexts (or 'namingContext' as referred to by the Root DSE).

A practical approach to distinguishing each tenant is to allocate their own individual Naming Context. A Distinguished Name (DN) can then identify each tenant, for example, if your service provider is called 'myservices' and owns the domain 'myservices.org', then it is common practice to give each tenant a subdomain. For example, 'customer1' could use the subdomain 'customer1.myservices.org'.

o=customer1, dc=myservices, dc=org

A 'customer2' could be formed by switching the RDN 'o=customer1' by 'o=customer2'.

Substructure

Given this naming convention for tenants, it is essential to establish a distinct tree structure for every tenant, which can be tailored to meet your particular requirements. Nevertheless, it is crucial that the substructure of the tree is identical for each tenant.

This standardisation eases the process of accessing each tenant and is particularly imperative if you wish to implement a website that enables your customers to manage their identities independently. Also, integrating standard software such as Keycloak or MIT Kerberos will be easier if all tenants adhere to the same structure.

An example structure could be:

dc=myservices, dc=org
 + o=customer1
   | ou=users
   | ou=groups
   | ou=hosts
 + o=customer2
   | ou=users
   | ou=groups
   | ou=hosts

Control Access

This blog post solely focuses on Identity Management. However, it is important to note that access management is necessary to improve the security and isolation of our tenants' data.

It is a fundamental principle that access for anonymous users must be prohibited and authenticated users should be restricted. Access will only be granted if a user, whether human or machine, belongs to an institution and has the necessary permissions to read or modify the data.

Most directory services offer some form of Access Control Instruction (ACI) or Access Control List (ACL) to manage user rights. Therefore, it is a recommended practice to implement ACIs to limit user access to the read privileges of their own tenant. Moreover, users should only be permitted to modify their own attributes except for their passwords. For sensitive changes, only special privileged accounts should be authorized to make modifications.

Summerising

Using multitenancy architecture to design Identity Management solutions as a service provider brings numerous benefits. Firstly, scaling becomes easier as there is no need to handle multiple instances with their network requirements, allocate computing resources and suchlike. Furthermore, standard tools such as LDAPv3 compliant Directory Services or Rational Database Management Systems can be used to implement a multitenancy IdM solution for your service provider. Finally, the approach enforces a certain level of standardisation among customer data structures.

However, there are a number of downsides to such an approach. Ensuring no overlapping visibility between tenants while accessing data is more intricate than deploying an isolated instance. Consequently, updating and releasing a new version of your IdM becomes more challenging as applying fundamental changes will immediately impact all tenants.

Yet multi-tenancy is the way to go to become a cloud service provider. Utilising standard tools enables integration of various commonly used tools such as Keycloak or MIT Kerberos, for example.