Een Nederlandse versie van dit artikel is hier te vinden: Gebruik van single- en multi-tenant diensten bij SURFconext.

Introduction

The services connected to SURFconext are mostly cloud services from external suppliers. The suppliers generally provide these services as SaaS, Software-as-a-Service. The supplier handles the infrastructure, applications and software for the service, so that the institution has nothing to worry about. The institutional user is subsequently granted access to this software, filtered via SURFconext.

Suppliers make their service available to one or more institutions, and can use different architectures. This article describes the possibilities service providers have for offering scalable SaaS services to institutions via SURFconext.

An institution already participating in SURFconext that wishes to provide their own institutional service via SURFconext can also make use of the technologies described in this article. However, this will only be relevant if the service will be offered to multiple other institutions.

What do single-tenant and multi-tenant mean?

A tenant is a group of users with the same access rights for specific software. A single-tenant service is a service or software instance that can only be accessed by one group of users. A multi-tenant service is a service multiple groups of users have access to. In a multi-tenant service, these groups each use their own section of the software, underlying database, etc. These groups are shielded from each other and cannot access each other's data. This makes the multi-tenant service appear to be a separate service for each other's individual group. This is explained in detail in a subsequent paragraph.

Please note, this refers to access to the service, rather than access rights within the service. There may still be various roles within the same tenant, for example an administrator with more rights than a regular user.

Within SURFconext, a participating institution is an example of a tenant. A single-tenant service is designed for one specific institution. Mediasite is an example of a single-tenant service. This video service provides an institution with the option to deploy their own version of the video platform. SURFconext links the institution to this version of the video platform, providing access to a single tenant.

Multiple institutions can use a multi-tenant service. The multi-tenant service can recognize the groups in a variety of ways:

(1) The standard method is for SURFconext to refer all institutions to one multi-tenant service. Before logging in to the service, the user will need to select the institution he is from. He is shown a ‘WAYF’ (Where Are You From) screen from which he can select his institution. Once the user is logged in, the service is given access to various user data (in the form of attributes; more information about attributes may be found on this Wiki page based on which the service can assign the user to the appropriate group.

The service can now strictly separate users from different institutions, giving the impression that the service is specifically designed for a single institution.

However, most multi-tenant services are designed in a more flexible manner, and can also facilitate inter-institutional cooperation. EDUgroepen, for example, allows logging in with an institutional account and creating a group (or team) with members from your own institution. However, employees of other institutions can also be granted access to documents in the service. This additional access can be granted on an individual basis, or based on groups in SURFconext Teams.

(2) Another less common option is to directly link an institution to an existing group within the multi-tenant service via SURFconext. An example of this is Google Apps for Education. The group is recognized by the subdomain; for example, the SURFnet URL is: google.com/a/apps.surfnet.nl. Only SURFnet employees have access to this. Other institutions are given a different subdomain.

Please note that for the ‘outside world’, this is simply a single-tenant service. SURFconext views each subdomain as a separate service and creates direct connections between the institution and the service.

A Service Provider has several options to let users choose which Identity Provider they wish to use for logging in. By default, SURFconext offers a WAYF page. Using this requires no extra effort from a Service Provider. However, a Service Provider may also create it's own WAYF page, or specific login pages for each Identity Provider. The division between single- and multi-tenant is not relevant here. This Wiki page explains how to build your own WAYF page.

Single-tenancy and basic architecture

In order to provide SaaS, the supplier has to deal with various components. To aid explanation, these are divided into three layers:

The (virtual) hardware layer. These are the physical (or virtual) servers used by the supplier to host the applications. For the sake of simplicity, the network and physical location underlying this hardware layer are also included.
The generic application layer. These are the applications used by the supplier within which the software runs. For example, web servers.
The service / own software layer. This is the supplier’s software that provides the specific service. This final layer is also divided into three layers:
- The database layer. The layer where data is stored.
- The business layer. The layer where the data is processed. This layer determines the functionality of the service.
- The presentation layer. This is the layer where the data are presented, for example in the form of HTML in a browser or app.

In a single-tenant architecture, each group of users has their own instance of all of these layers. For a service used by three individual institutions, the structure looks like this:

SURFconext - Get Conexted > Use of single-tenant and multi-tenant services in SURFconext > tenancy01.png

If a fourth institutions wishes to use the service, additional (virtual) hardware would have to be deployed for this institution, on which the applications would be installed along with a new copy of the supplier’s software. All of it specifically for the fourth institution.

Single-tenancy and sharing resources

In addition to strictly separating resources for various institutions, some resources may also be shared. This means that various layers can be shared by multiple tenants, without affecting the end-user’s perception - the latter can only share data with his own group.

The supplier can often determine which layers can and cannot be shared from an efficiency standpoint. It is common in this case to share generic resources while keeping application specific resources strictly separated. Maintaining data confidentiality between various tenants always remains the key consideration.

Multi-tenancy

The ultimate sharing of resources between various groups is achieved if the presentation layer is also shared between all groups of users. This also obsoletes the individual access portal for each individual group. This is precisely what is achieved with multi-tenancy.

Multi-tenancy means various groups of users can use the same service, while shielding groups from each other and only providing access to the group’s own data. The architecture looks like this:

SURFconext - Get Conexted > Use of single-tenant and multi-tenant services in SURFconext > tenancy06.png

In this scenario, if a fourth institution wishes to make use of the service, little is required from the supplier. It generally entails adjusting the system configuration, after which the fourth institution can start using the service.

Architectural considerations

Single-tenant and multi-tenant architecture each have their own advantages and disadvantages. There are a number of factors that can lead to a preference for one architecture over the other. There are technological considerations in the following areas:

1. Flexibility:

- A single-tenant architecture allows for flexibility. Because a change in hardware or software for one tenant does not affect the other instances. This provides complete freedom to customise the software to suit the institution. However, offering such flexibility entails a significant administrative burden for the supplier.
- Note that this flexibility can also be realised in a multi-tenant environment like the one described in the final chapter of this article. This requires a greater degree of initial software development from the supplier, but results in a lesser administrative burden later on.

2. Security:

- A single-tenant architecture is considered more secure, primarily because the data for each institution is stored in a separate database and thus cannot be mixed.
- On the other hand, in a multi-tenant solution, it is in the software provider’s interest to ensure the data are secured. Precisely because more attention is given to security in the latter environment, this may be advantageous.

3. Upgrades and release management:

Upgrades can be rolled out individually per tenant in a single-tenant environment.
In a multi-tenant environment, an upgrade to hardware and/or software immediately goes live for all parties. All parties benefit from the development. The disadvantage is that there is no room for individual releases.

4. Migration and availability:

A single-tenant environment is relatively easy to back up and migrate to a different location, even from the cloud back to on-premise.
A multi-tenant environment can be migrated to another location entirely in the cloud. A move from the cloud to on-premise is often impossible. In multi-tenant environments, uptime is often a more pressing concern, as the impact of downtime is significant and affects all tenants.

5. Scalability and efficiency:

A single-tenant architecture is scalable, but not efficient, because each tenant requires a full environment.
For the supplier, support for a multi-tenant architecture is more easily scalable and more efficient than a single-tenant architecture. This is because each instance benefits from the others’ capacity.

Suppliers of cloud services are increasingly offering multi-tenant architectures because scalability & efficiency (5) and upgrades & release management (3) in this environment are much more easily realised. Additionally, there is growing attention for flexibility (1) and security (2), which will lead to higher initial costs for software development, but longer term cost savings thanks to sharing of resources. Migration (4) is a less pressing concern for a supplier of cloud services, but availability is all the more important.

Recognizing the user group with SURFconext

SURFconext creates connections between institutions (IdPs) and service providers (SPs). These connections differ for single-tenant and multi-tenant services.

In a single-tenant environment, the user is easily recognized, because SURFconext only connects the IdP in question to the service, so only users of that specific institution can log in to the service. This means SURFconext must create a separate IdP and SP connections for each single-tenant. This results in a large number of connections and a high administrative burden for SURFconext and the service provider.

In a multi-tenant environment, SURFconext connects multiple IdPs to one service. The art is for the SP to, where necessary, recognize the user knocking at the door in a multi-tenant environment. This can be easily achieved by the user attributes SURFconext provides. For example, the attribute: 'schacHomeOrganization' for identifying the institution, or 'eduPersonPrincipalName' for unique identification of users per institution. Based on these attributes, the software can determine which group the user belongs to. In a multi-tenant environment, the group is thus easily recognized based on user attributes.

A service can also use external group information, for example from SURFconext Teams or directly from the institution’s own Group Provider. This information can be used to make authorisation decisions. The service can request user membership status for a specific group via the VOOT API. For example, members of a specific group can be granted access to a specific section within the service.

Advantages of a multi-tenant environment within SURFconext

The advantage of a multi-tenant environment for SURFconext, the supplier, and the institution is that SURFconext can quickly and easily (with a single configuration setup) connect a new institution to an existing SP. Furthermore, the environment is tried and tested; after all, other tenants are already using it.

In contrast, every new single-tenant service requires the supplier to create a new SP and SURFconext to create a new connection. This requires far more development and testing time.

This means a multi-tenant SP can be deployed much faster, and thus can grow much more quickly, while the effort required to recognise a user in the software is relatively small.

Specific SURFconext user groups in a multi-tenant environment.

Flexibility is often regarded as an advantage of the single-tenant environment. This may appear to be the case at first, but a mature multi-tenant environment can provide the same level of flexibility with its own software. This is because the user is recognized based on institutional attributes and/or group membership on entry.

Extensive authorisation decisions can be made within the software based on attributes and group membership. For example, a separate interface can be displayed for people from a specific institution within the presentation layer. A specific group of people can also be given additional functionality within the business layer. For example, the difference between an employee and a student, based on the 'eduPersonAffiliation' or the ‘eduPersonScopedAffiliation’ attribute. Separate databases can even be accessed in the database layer based on attributes. The following figure displays what can happen within a layer. The colours indicate separate interfaces, functionalities and databases per target group.

SURFconext - Get Conexted > Use of single-tenant and multi-tenant services in SURFconext > tenancy07.png

Specific groups can be formed within the application by distinguishing between users based on attributes and groups. The attributes a supplier can use are described in the SURFconext Wiki. For more information about attributes and requesting attributes and group membership in SURFconext, please refer to these pages:

Ways to make an SP multi-tenant

First of all the service can be made inherently multi-tenant, where there is a shared infrastructure used by all customers. There's one SP that uses attributes to identify different customers.
When a service uses different instances for different customers nonetheless, one can centralise the authentication component in the platform, used by all the instances. When needed, different ACS locations can be defined in metadata for one SP, making it possible to use different URLs with the same metadata.
You can install a Service Provider proxy that operates as one SP in the direction of SURFconext, and that services all the instances internally.