for Multi-tenant and SaaS Applications
What is a multi-tenant application?
Multitenancy is a concept where a single copy of an application is running on a server, and is
used simultaneously by multiple client organizations (tenants). The application is designed to partition
its data and configuration, so that each client organization works with a customized and private instance of
We see two types of multi-tenant application most often:
- In-house applications: developed by large organizations
and used at a distance by their Entities, Agencies, Subsidiaries or
- Commercial applications: SAAS applications, hosted
in a public cloud and used by multiple customers.
How to secure multi-tenant applications
As with any other application, you may want to secure these applications
with user authentication, user permissions and auditing features.
In such a case, multitenant applications need to meet several criteria:
1 - Protect Data from Other Tenants
The perceived risk of data disclosure is greater with multi-tenant applications.
Users should trust their private data is secure, although they are sharing
the application with other organizations.
A robust Access Control system isolates each tenant's data to provide a suitable level of protection.
This system should provide the following features:
- Defining and Managing tenants (sets of users)
- Defining and Managing user accounts as members of a tenant
- Restrict access to data within each tenant
2 - Delegate administration privileges
The owner of the information should have the ability to decide who is able to view and access it. Each client
organization should be able to independently customize access rights for each user.
Therefore, Access Control systems should allow users to:
- Delegate security administration to local managers within each Client
- Protect data confidentiality: a tenant administrator should not have access to other tenants’ security data
- Preserve data availability: while data needs to be secure, it also needs to be accessible and available in a timely manner. So do administration features
Managing independent tenants
The access control system must be able to replicate any existing repartition
of the « sets of users ». Visual Guard allows you to define a user group
hierarchy, with each group containing users or other groups.
Example 1: a commercial SAAS application might put their « Clients »
at the first level in the hierarchy. Each client would then create
their own sub-groups to recreate their organizational structure.
Example 2: an administration can define a tenant for each agency that uses
their system. If these agencies are part of the administration’s
departments or divisions, they can be places at lower levels in
Example 3: if an
organization needs to manage a mixed population of internal and
external users, it can define tenants to manage each set of users
Note: in this situation, VG also allows you to combine autentication
with Windows accounts (internal users) and username/password accounts
(external users). For more information, please
see mixed-mode authentication.
Apart from these basic examples, Visual Guard supports multiple other
configurations. For example, you can authenticate users with their Windows
accounts, whether or not each tenant uses its own Active Directory. In
this case, Visual Guard allows you to federate multiple Active Directories
that don’t belong to the same network (for more, see
Identity Federation). In certain cases, you can also implement Single
Sign-On (SSO) based on the user’s Windows account.
You can define group hierarchy from:
- The Visual Guard Windows Console
- The Visual Guard Web Console
- Your application(ASP.NET or WCF/Silverlight for example) that calls
the Visual Guard API
Restricting the administration rights to a tenant
In general, Visual Guard allows you to give privileges to an administrator
so that they can manage users and give permissions for each application.
Administration privileges can also be limited to a group of users. In
this case, the administrator can only see and manage the users in their
When working with a multi-tenant application, it is recommended to name
at least one administrator per tenant, and to limit their administration
rights to that tenant.
Example 1: you can name an
administrator for each tenant
However, Visual Guard can do much more: we can limit administration permissions
to any level of the group hierarchy. This system offers a great deal of
flexibility for the distribution of administration rights in any entities
within each tenant.
Example 2: you can limit administration to a sub-group inside a tenant
To go further:
You can combine multiple criteria to limit administration permissions
- As shown above, you can limit these permissions to certain groups of users
- You can also limit these permissions to certain applications
- You can limit them to certain administration operations (for example, the administrator can create users and give
them Roles, but cannot define Roles)
Example 3: you can define several administration levels in each tenant
Making Administration features accessible to each tenant
It is important to simplify access to the administration features:
- Multi-tenant applications are used over multiple sites. The administration interface should be as easily
deployable as the application itself.
- To be able to distribute administration rights in a way that is very flexible, each user should be able to
access the administration features, no matter where they are or their technical skill.
By default, the two main solutions are as follows:
1 – Visual Guard Web Console:
- This application allows you to manage users and their groups, roles,
- It consists of a web application (asp.net), which is accessed by
a simple browser
- It can be deployed with the application and is accessible to the
- It includes an extension mechanism: Visual Guard consultants can
add custom asp.net pages to the Console to comply with specific security
- You will find more information on the VG
Web Console here
2 – Custom Administration User Interface:
- A custom ASP.NET or WCF/Silverlight administration interface can
also be developed
- It can be deployed as a separate administration console, or integrated
into your application
- They call the Visual guard APIs to perform all necessary administration
operations. These APIs are secured as described above. They allow
you to, in particular, manage the tenants and delegate the administration
restrictions to each tenant. You will find for information on the Visual Guard APIs here
- You can develop these custom forms or entrust this task to our Visual
Audit: Centralized or Distributed View and Control?
Similar to the administration rights, it is also possible to both give
and limit permissions to see and control the multitenant application security.
Depending on the circumstances, we may wish to either centralize or distribute
Example 1: in-house applications used by several entities
of a large organization
- By default, this type of application requires centralized control for its security
- The auditor must be able to see all access rights and all sensitive operations performed, regardless of the
users, departments or tenants concerned
- Each organization is then free to limit the scope of the auditor to certain sets of users and / or applications
Example 2: SaaS commercial applications used by multiple
- The software vendor may offer each client the ability to control security for its users. In this case, the scope of
each auditor is limited to a tenant (client).
- The auditor of each tenant can see the access rights of their users. They may also control operations performed
by the users and administrators of their tenant
- If necessary, the software vendor can control certain operations performed by their clients. This may be useful
in some cases of technical support, for example to understand the history of the application’s use and administration
How to secure multi-tenant applications
Developers define permissions with the VG Win Console.
Permissions are stored in a development repository.
Developers deploy the permissions into production with a VG
Administrators manage Users and grant them permissions.
They may or may not belong to a tenant.
Their administration privileges may be restricted by tenant,
by user group, by application, by type of operation, or any
End-users log in to the application and VG secures the application
as any other application.
By default, they use login/pwd accounts. They can also use their
own Windows Account (cf. Identity Federation).
Their operations may be logged in the VG Repository
Auditors can control user attributes, roles and privileges across
multiple systems. They can also review user operations.
They may or may not belong to a tenant.
As for administrators, their access may be restricted by tenant,
by user group, by application, or any possible combination.
- These features are available for any technology supported by
VG, in particular .NET applications ( Winforms, asp.net, WPF,
- Administrators and Auditors can operate from any location with