Introduction

The CoreOne Suite offers various tools and patterns to cover a multi tenancy environment. Depending on the use case you can choose one deployment scenario or even combine some of them. Below you will find an overview of all possible deployments.

Open

Logical Tenant Seperation

Each entity within the CoreOne Suite Meta Directory has a tenant_id associated with it that references the tenant entity. That entity itself has a parent_id and let’s you therefore create a logical tenant tree. By assigning each entity to a logical tenant you clearly associate each entity to said tenant. In many places that association will then be taken into account. To give an example we can look at the organizational tree and the employments. If you create a new employment, you first have to select the tenant that this employment belongs to. Dependend on the selected tenant, you then can only select organizational units that are associated to that tenant.

The following rules apply for this deployment scenario:

• Each data record is associated to a tenant

• There is one single database, the data storage is not separated for multiple tenants

• The actual data is not physically divided, there is only one AppCustomer

AppCustomer Seperation

The CoreOne Suite supports the creation of multiple AppCustomers. An AppCustomer is represented as a seperated schema within the same database. Therefore the underlying hardware can be shared but the data is stored in a dedicated schema and therefore logically seperated from other AppCustomers.

The following rules apply for this deployment scenario:

• Data records are stored in the appropriate AppCustomer schemas

• There is one single database, but data storage is seperated on schema level

• The actual data is logically divided, there are multiple AppCustomers

Physical Seperation

By actually installing the CoreOne Suite multiple times the data is completely separated.

Logical Security Seperation

With the Advanced Permission Management of the CoreOne Suite you can configure security roles that gives users access to only selected data. This allows you to configure a wide variety of use cases with endless complexity. You can configure use cases such as give users only access to data that is associated to an organizational unit below the Legal Entity that they are employed to.

Combining

All the described deployment scenarios can be combined. This allows you to find the best combination for your use cases. It’s also possible to migrate from one deployment scenario to another. But be aware that even though this is possible, it’s not an easy task to do. So be sure to select the ideal scenario for your use case.

Things to consider

Authentication

Each App Customer and each separate instance has its own Identity Provider and therefore its own user base. Especially when using the system as an IdP, this has major implications as usually a relying party only has one IdP associated. Let’s assume you have an customer relationship portal where both employee as well as customers should have access to. You could seperate the customers in one AppCustomer and the employees into another AppCustomer, giving you a clear seperation of the data. For the customer relationship portal you are now facing the challenge, that the portal only has one IdP. So you need to either choose the customer AppCustomer and configure a federation for the employees or combine both user groups in one AppCustomer.