Skip to main content
Version: 2022

Tenants

Introduction to tenants

note

To make the right choice for your organization, see: Multi-tenant solutions and alternatives.

Tenants are isolated environments where administrators can work solely with their own users and user groups. Every user and user group can be a member of a single tenant. For Independent Software Vendors (ISV's), the term 'tenant' in a SaaS environment can usually be exchanged with ‘customer’.

For a root administrator, the following tenant information is accessible:

  • Users.
  • Administrative powers of users.
  • User groups.
  • Granted application(s).
  • Assigned and unassigned roles per application.
  • Granted modules per application (see Module authorization).
  • Assigned and unassigned roles per module.
note

All tenants are visible for Main and Application administrators. Other administrators can only see, add, and update users and user groups that are from the same tenant. For more information, check out Administrator roles.

In a multi-tenant SaaS environment, having an application in IAM per customer is strongly advised. When every customer has their own product database, having an application in IAM per customer is the only option. However, this can also be done for a multi-tenant product database. This will allow you to tailor application-specific settings such as file storage, scheduling options and global variables for the application.

Below is an example of module authorization combined with multi-tenancy. All modules are synchronized to IAM, where ISV administrators can configure the tenants and applications with a limited number of modules. The tenants are present in two SaaS environments, IAM Acceptation and IAM Production. Of course, if necessary, more environments can be configured.

Note that the configured modules for a tenant may be different per environment. This can occur when a customer is preparing to purchase a new module.

DTAP environment for tenants

Create a new tenant

One tenant is included in every IAM by default. For this tenant, the Default tenant box is checked. This can be changed, but only one tenant can be the default tenant.

New tenants can be created in the tenant screen:

menu Authorization> Tenants

Tenants

Assign a tenant to groups and users

After a tenant has been created, it can be assigned to user groups and users:

  • User groups: the field Tenant is available for each user group in the menu Authorization > User groups > tab Form.

  • Users: the field Tenant is available for each user in the menu Authorization > Users > tab Form.

Move a user to another tenant

menu Authorization > Users

  1. Press the task for moving a user to another tenant. Only Root administrators can use this task.

Move user to tenant Task for moving a user to another tenant

  1. Select the tenant you want to move the user to.

Move user to tenant Move a user to another tenant

Copy a user group to another tenant

menu Authorization > User groups > tab List

  1. Press the task for copying a user group to another tenant. Only Root administrators can use this task.
note

The task will only copy the user group, not the users, because the users are assigned to a tenant.

Copy user group to tenant Task for copying a user group to another tenant

  1. If necessary, check the Include authorization box to include the active roles into the copy of the user group.

  2. Select the tenant you want to copy the user group to.

Copy user group to tenant Copy a user group to another tenant

Limitations to tenancy

Some features in the Thinkwise Platform are not, or only limited suitable for multi-tenancy:

  • OpenID Connect: OpenID Connect, both acting as server and as client, can be configured only for all tenants at once. For instance, to log in to the application using Google accounts, to log in to a helpdesk using IAM accounts, or single sign-on without a prompt for a username/password. After all, the tenant is not known until the user is logged in. So, OpenID Connect cannot be configured per tenant without affecting other tenants.

Tenant overview

The access to applications and modules can be viewed from a tenant's or an application's point of view:

Overview per tenant

To view a tenant's current access to applications and modules:

menu Authorization > Tenants > tab Form

Overview per tenant Access overview per tenant

To delve deeper into the details:

  • tab Application administration analysis: for each application, the assigned administrative roles for each tenant, both root IAM administration and tenant self-administration.
  • tab Current access analysis: for each application, which users have access to which module.

Overview per application

To view per application which tenants have access and administrative access:

menu Authorization > Applications > tab List

Two columns are important here:

  • column Accessible by tenants: information about which tenants have access.
  • column Administrated by tenants: which tenants have administrative access.

Access per application A tenant's access per application

To delve deeper into this information for the selected application, two cubes are available:

menu Authorization > Applications > tab Analysis

  • tab Application administration analysis: for each application, the assigned administrative roles for each tenant, both root IAM administration and tenant self-administration.
  • tab Current access analysis: for each application, which users have access to which module.

Tenant analysis Per application: further analysis of a tenant's administrative roles

Multi-tenant solutions and alternatives

Not every scenario is suitable for a multi-tenant solution. Functional differences might make it more feasible to create a multi-instance solution. Furthermore, a multi-tenant IAM does not mean the product also has to be multi-tenant. You can tailor your environment to your functional and non-functional needs.

The table below is by no means complete but should provide some food for thought for the functional- and non-functional aspects of the various tenancy architectures.

Note that for every drawback, there is more than likely a way to work around it with the right tools and the right amount of effort.

  • A Multi-tenant IAM & Multi-tenant product excels for ISVs that provide a consumer-grade SaaS application that is lightweight in use. Usage of customers is unlikely to affect one another. The customers will have little to nothing to demand when it comes to SSO integration or application versioning. Margins are usually tighter, so cost reduction is key.

  • The Multi-tenant IAM & Multi-instance products approach works well for heavyweight applications or applications that contain sensitive information. Customers may have different SLAs when it comes to application performance and uptime. These customers may request their application to be restored to an earlier point in time if they make an irreversible mistake.

  • Multi-instance environments are best for enterprise-grade applications that need to be tailored towards demanding customers. SLAs may include SSO integration, performance scaling, and globalization. These customers may choose to hold off on platform and application upgrades. The isolated nature of these environments makes them most secure. On-premise deployment is an option as an alternative to SaaS.

Multi-tenant IAM & multi-tenant productMulti-tenant IAM, single tenant productMulti-instance environment
Customer-specific OpenID server--+
Customer-specific SSO--+
Customer-specific user self-registration (future)--+
Customer-specific 2FA/password reset e-mails--+
Customer-specific branch-++
Share base data+--
Uage analysis over multiple customers++-
Perform product data analysis over multiple customers+--
Minimize operational costs+++-
Minimize impact of security breaches---+
Prevent heavy product operations from affecting other customers-++
Prevent heavy runtime/IAM operations from affecting other customers-++
Customer-specific SLA regarding database scalability-++
Customer-specific SLA regarding webserver scalability--+
Customer-specific globalization/datacenter options-+++
Insight in customer product database hosting costs-++
Insight in customer runtime/IAM hosting costs--+
Gradually upgrade to new Thinkwise Platform versions--+
Quickly upgrade all customers to new Thinkwise Platform versions++-
Gradually upgrade to new product versions-++
Quickly upgrade all customers to a new product version+--
Customer-specific back-up and restore-+++
Quickly remove a customer and all its' data (GDPR)-+++
Migrate a customer to on-premise or different cloud provider--+

Was this page helpful?