Multitenancy

Multitenancy allows a BL to share an instance of the Ability™ Platform among multiple entities. Data isolation is built into each of the Ability™ Platform resources and access to this information is secured via fine-grained access controls that prevent unintentional or malicious access.

The primary benefit of supporting multitenancy in the platform is to reduce the operational and management costs by sharing the software and infrastructure.

As Wikipedia puts it:

The term "software multitenancy" refers to a software architecture in which a single instance of software runs on a server and serves multiple tenants. Systems designed in such manner are often called shared (in contrast to dedicated or isolated). A tenant is a group of users who share a common access with specific privileges to the software instance. With a multitenant architecture, a software application is designed to provide every tenant a dedicated share of the instance - including its data, configuration, user management, tenant individual functionality and non-functional properties. Multitenancy contrasts with multi-instance architectures, where separate software instances operate on behalf of different tenants.

In practice, multitenancy allows you to create a solution that you may expose to multiple tenants - via a contract. A solution might contain a collection of applications and grants that provide permission to access the data. Since your customers are most likely separate entities, they should not share data. Even though they would all use the same solution that you have developed for them, the data that they see is private to them and inaccessible to other tenants.

Learn more about these concepts in the terminology article.

Single-tenancy vs multi-tenancy

In a single tenant systems, all resources that the system consists of are for the sole use of one tenant (customer(s)). In contrary, the multi tenant system tries to optimize costs by sharing as much of the resources as possible between multiple customers (while keeping their data separate). The cost is really the key point here - having one multi-tenant system results in huge cost savings when compared to deploying multiple single-tenant systems.

An analogy of housing could be used to present the difference. In this analogy, a single-tenant system would be a single-family house:

As you can imagine, each new family that moves into the area, needs a new house. Each house requires its own heating system, water connection, electricity connection, etc.

Now, let's compare it to a multitenant system. In our housing analogy, that would be represented as a block of flats:

Without pushing the analogy too far, you can imagine that in a multi-tenant system some of the resources could be shared between the tenants.

An important thing to note here is that Ability Platform, like any other system, has limitations. I.e., multitenancy does not equal inifinite number of tenants. The fact that platform allows multiple tenants to share one instance does not mean that there is only one global instance of the platform used by everyone. There are many factors (regulatory, business, technical, etc.) that disallow that.

Max Number of Tenants

The Ability Platform uses Azure AD B2C to manage user sign-in, as well as issuance of access tokens for access to the Ability Platform APIs. The configuration of authentication in Azure AD B2C is achieved via "policy documents" stored as XML files in Azure AD B2C.

By default, the policy limit per B2C instance is 100. However, this can be increased to a limit of 1000 policy documents per B2C instance by contacting your CST representative to help connect you with Microsoft support. This is a limit imposed by Microsoft and not by the Ability Platform.

The following types of documents are created in the Azure AD B2C and limit the number of tenants that can be associated to a solution:

• A Base policy (1 document at the time of deployment of Ability Platform)
• An Extension policy (1 per tenant created in Ability Platform)
• RP policy for background application authentication (1 document)
• A Relying-Party policy (1 per contract created in Ability Platform)

By default, deployment of the platform creates 4 policy files (1 Base, 1 for ABB Ability tenant, 1 for Background applications and 1 for a contract between an Ability Platform solution and the ABB Tenant).

During deployment, a base and RP (including extensions) for an Ability tenant is created. At the time of adding a tenant, an RP per tenant is created (including the tenant specific extensions). At the time of creating a contract, no policies are created.

Ability Platform Layers

Considering that there are in fact multiple instances of the Ability Platform, the following "layering" was implemented to reduce the costs.

The platform is separated into three planes/layers:

• Global - contains resources that should be used globally, like UUID generation and Ability PKI
• Region - contains Azure Device Provisioning Service and Principal Management capabilities
• Instance - contains the Instance API and all resources needed for its functionalities.

TIP

From the perspective of developers, who are building solutions on top of Ability Platform, it does not actually matter that the platform is separated into these layers. All they need to know is the set of URLs and parameters that allow them to communicate with Platform's resources. The fact that some resource might be in a different plane does not change anything for a developer.