Multi-Tenant

Description

Default Record: This is ticked on if this is the default settings record. In a single tenant situation there should only be a single record in the settings table, and this field should be checked.

Company: The name of the company that uses these settings. The value in this field needs to be unique. In multi-tenant situations the company name is used to distinguish between tenants. when users log in they will need to identify the company they are logging into.

PIN: A PIN code identifier for the company.  The value in this field needs to be unique. The use of PIN codes allows users, in a multi-tenant setup, to easily identify the company they are logging into (without needing the whole company name). It is most useful in situation when displaying a list of companies, and asking the user to select the correct one, is not desirable.

Multi-Tenant support is optional. It is more likely to occur in a web context than a desktop context. You can design a system to be single-tenant, and expand it to be multi-tenant later if you so wish.

Introduction

In a Multi-Tenant situation multiple distinct groups of users exist. These groups are known as Companies. Before the user can login they (may) have to first identify which company they are logging in to.

Each company will have a record in the Settings table. In a single-tenant case a single record will be created in the table. One of the records (or the only record) in the table will be a designated "Default Record" and this in turn will be the default values for any other companies that are added to the list.

Users and User Groups belong to a specific company. If a user wants to access multiple different companies they will need to be added to multiple times (and will then exist as distinct users)

Company-And-User versus Unique-User

There are two ways to identify a user.

Company-And-User

In this approach the user name and company together are unique. This approach allows for multiple different users to exist, with the same user login - as long as they are for different companies.  So two customers could each have a user login (called say Humperdink), but since the company is also captured during login it is clear who is logging in.

This approach is more flexible, but does REQUIRE that the user identifies which company they belong to. (This may be active, as in selecting from a list, entering a PIN code or passive - like by using a specific URL.)

If the system is single-tenant then that company is assumed, and the user does not need to identify the company.

Unique-User

In this approach the user name must be unique across ALL users in the DEX database, regardless of which data set they will be accessing.

If Humperdink already exists for one tenant, then another tenant may not also create a user called Humperdink. This is not a huge issue for people related login names, (people can be very creative with their login names) but it can become an issue when more generic names would be used. For example Administrator or Sales or other generic titles like that.

Login names in this situation are unique, so there is no need to select the company during the login process - since the user is unique, and the user is assigned to a company, the company is known when the user name is entered.

In Self-sign-up  situations it would still be necessary to determine which tenant the user was signing up for. Again this might be via selection from a list, PIN code, or URL.

Note: In this approach if a new Settings record is created (ie a new Company) then a new user MUST be created at the same time to login to this company. If no user exists for a company, then it's not possible to log-in to that company.

Login Procedure

If multiple tenants exist, and the Company-And-User approach to login names is being used, then the user will need to identify their company in the Login procedure.

This is done via a Browse Control on the Company tab.  The goal of this control is to set the Login field to the value that the user selects.

This approach is easy for the user, but does show the user a list of tenants. In some cases this may not be desirable. If this is a problem then entering a unique PIN code for the company can be used instead. This PIN code is set by the SysAdmin user when creating the company. A PIN field exists on the tab, and can be unhidden when the Browse control is deleted.

Multi Tenant <> Distinct Data Set

While it is probable that each tenant will have a distinct data set (ie in a different database, or different TPS folder) the two concepts should not be conflated.

Having multiple tenants does not imply multiple data sets. And multiple data sets does not imply multiple tenants. It is possible to have multiple tenants sharing the same database, and it's possible for a single tenant to have multiple data sets.

Managing multiple data sets is a completely different task to program access control, and so it falls outside the scope of what Secwin provides. It should in turn be compatible with any dataset-manager that you use.