Access Control 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 the application.

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 Business Associates
  • 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 organization
  • 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 the hierarchy.

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 independently.

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 group.

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.

Naming an Admin for each 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.

Limit user administration to a sub-group inside a 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, permissions, etc…
  • 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 same users
  • It includes an extension mechanism: Visual Guard consultants can add custom asp.net pages to the Console to comply with specific security requirements
  • 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 Guard consultant

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 these permissions.

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 customers

  • 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

Securing Multitenant Applications
  1. Development
    Developers define permissions with the VG Win Console.
    Permissions are stored in a development repository.
    Developers deploy the permissions into production with a VG utility

  2. Administration
    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 possible combination.

  3. Enforcement
    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

  4. Audit
    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.
Notes
  • These features are available for any technology supported by VG, in particular .NET applications ( Winforms, asp.net, WPF, WCF, Silverlight...)
  • Administrators and Auditors can operate from any location with Internet Access

Reference Sources:
http://en.wikipedia.org/wiki/Multitenancy