Tenants

Introduction to tenants

note

All tenants are visible to Main and Application administrators. Other administrators and owners can only see, add, and update users and user groups from their own tenant. For more information, see Administrator roles.

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 (ISVs), the term 'tenant' in a SaaS environment can usually be exchanged with 'customer'. See also Tenants (definition).

For a main 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.

In a multi-tenant SaaS environment, we strongly advise to add an application for each customer in IAM. If every customer has their own product database, an application for each customer is the only option.

You can do the same for a multi-tenant product database. This allows you to tailor application-specific settings such as file storage, scheduling options, and global variables for the application.

note

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

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.

A DTAP environment for tenants

Limitations to tenancy

Some features in the Thinkwise Platform are not or not fully suited 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.

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 product	Multi-tenant IAM, single tenant product	Multi-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	+	-	-
Usage 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	-	-	+

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

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.

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.

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

Create a new tenant

main administrator

By default, every IAM includes one tenant, marked with the Default tenant checkbox.

To create a new tenant:

menu Authorization > Tenants > tab Form

1. Enter a Tenant name.
2. Optional: Mark the tenant as the Default tenant. Since only one tenant can be the default, saving this change will automatically clear the checkbox for the current default tenant.
3. Optional: Change the fields Session expiration and Extended session expiration. For more information about these settings, see Session expiration.

Assign a tenant to groups and users

main administrator

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

main administrator

menu Authorization > Users

1. Execute the task Move user to tenant .

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

Move a user to another tenant

Copy a user group to another tenant

main administrator

menu Authorization > User groups > tab List

See: Copy user groups in the User groups guide.

Notify all users in a tenant

See User notifications.

Tenant tags

main administrator

menu Authorization > Tenants > tab Tenant tags

Here you can maintain information about tenants that is not already available in the Intelligent Application Manager.

Tenants are not expected to be copied, so tags will not be included.

Session expiration

Indicium main administrator

By default, sessions in the Thinkwise platform expire after 30 minutes of user inactivity. When the session expires, the user must re-authenticate to access the Thinkwise environment. If a user selects the option Stay signed in, the session expires after 14 days of inactivity.

You can choose to create a custom session expiration period or not. If not, the global settings are used. See Session expiration (global settings) in the Users guide.

To configure a custom session expiration period for a tenant:

menu Authorization > Tenants > tab Form

1. Select the checkbox Custom session expiration.

2. Enter the desired values for:

   • Session expiration - This value specifies how long users can remain idle before the session expires and re-authenticate is required to access the Thinkwise environment. Users authenticated via OpenID will use the session expiration configured at the OpenID provider in IAM, see Register an OpenID identity provider.
   • Extended session expiration - This value specifies how long users can remain idle before the session expires and re-authentication is required when the option Stay signed in is selected.

An OpenID provider may also have its own authentication session expiration and Stay signed in settings. These settings only affect the user's session with the OpenID provider, such as the ability to quickly re-authenticate with it.