Software as a Service (commonly known as SaaS) is a rapidly growing business model. Many companies have adopted the SaaS model in their businesses for various reasons, such as flexibility and affordability. SaaS deployment allows multiple people to work on the same application instance either in isolation or a collaborative environment. 

This makes Multi-tenant architecture (or Multi-tenancy) a key characteristic for this deployment. 

Multi-tenancy is a software architecture where several customers, more often organizations, share a single, centrally maintained deployment of a software application and its database(s). The customers (or organizations) are known as Tenants in this model. The tenants work virtually in isolation, with their data, reports, and other resources separate and secured from other tenants unless shared through the data governance rules.

Multi-Tenancy with Wyn Enterprise

Wyn Enterprise's approach to multi-tenancy is flexible enough to be compatible with various deployment scenarios. It offers multiple configurations that authenticate the tenants and grant them access to their data only. The key configurations to set up multi-tenancy in Wyn include organization-context, user-context, user management, user claims (context or custom properties), security filters, and dataset filtering. These can come directly from Administrator settings or through Security Providers.

You can combine these configurations depending on the multi-architecture model, the services, and the nature of your business. Understanding these strategies is essential to embed BI securely into a SaaS solution using Wyn Enterprise.

When you host Wyn Enterprise for a SaaS deployment, the organizations (or tenants) log in through the Identity Server. Further, Wyn identifies the logged-in tenant through the deployed multi-tenant settings and gives it access to the authorized data through Wyn resources such as data sets, data models, reports, or dashboards, as shown in the image below:

There are many forms of multi-tenancy scenarios, and their implementation varies for organizations depending on several factors. These architectures vary in degrees of data isolation from an extreme of wholly isolated databases, where each tenant has their own copy of data, to shared databases where tenants share the same tables and data is associated with a tenant using a tenant identifier such as ID, Region, Company, etc.

We will touch on these two commonly adopted multi-tenancy models with a hosted instance of Wyn Enterprise and how its multi-tenant features are integrated with these environments.

Multi-Tenancy with Isolated Mode using Wyn Enterprise

Multi-Tenancy in Isolated mode using Wyn Enterprise is summarized in the image below:

In this mode of multi-tenancy implementation, data for each tenant is stored on separate databases, which may be on the same server or physically separated server instances. 

The databases often have different data structures - schema and tables and are thus created separately on the Wyn Enterprise. Such data resources are isolated using the Role-based permission model.

However, though the databases are separate in specific business scenarios, the schema and table structures are the same. Think of a hosted business application such as Sales Management, HRM, CRM, ERP, etc., having high compliance organizations as tenants, for example, government offices or big organizations. They have sensitive and regulated data and prefer separate databases to ensure data security and privacy. Thus, the system maintains separate tenant databases with the same schema structure as the SaaS application.

When such a system is implemented using Wyn Enterprise, creating and maintaining separate data resources leads to unnecessary administrative overhead. Additionally, it puts an additional load on the server, thus impacting the system performance. This raises the need for a database isolation logic that uses a single Wyn data resource to locate different databases. 

Wyn Enterprise connects to (or locates) a database through a Data Model or Data Source using a connection string. Thus, the logic can be added within the connection string.

You can use the database identifier in the connection string to differentiate the databases among the tenants (or organizations). This database identifier can be derived from an organization property in Wyn Enterprise. The syntax to add this property in the connection string is #{organization property name}. For example, a property named "CompanyName" is used in the connection string as follows:

Server=<server name>;Database=#{CompanyName};User Id=<username>;Password=<password>;

Follow the documentation to learn more about Organizations and their properties.

Multi-Tenancy with Shared mode using Wyn Enterprise

The shared mode of multi-tenancy with Wyn Enterprise is summarized in the image below:

In this mode of multi-tenancy architecture, the database (and table) is shared among the tenants, but the data is isolated logically. Consider a hosted CRM or ERP system where the tenants are small-scale organizations. A typical SaaS app in such a scenario implements a single instance of the database for such tenants. The hosted application stores the data for each tenant in the same table, with the records separated using identifiers like an ID, Region, or Location. To fetch the tenant-specific records, row-level data isolation is required in such an implementation. 

In Wyn Enterprise, a database table is abstracted by the DataSets or DataModel's Entities. For row-level data isolation, you can add a contextual Parameter in Dataset and Security Filter in a Data Model.

The organization context is used as the Parameter type in a multi-tenant environment with Datasets. This parameter is further used in the Filters to retrieve the tenant-specific information. See the documentation to configure the parameters and filters in a DataSet.

On the other hand, Security Filter is a logical expression that depends on how the multi-tenant environment is configured to identify the records available to a user. You can use the organization context as a value to this logical expression for the row-level filtering. Check out the documentation to configure a Security filter. 

These configurations are transparent to the business user and are applied when queries are run on the database. You can specify one or more parameters or security filters and fetch data specific to the current tenant.

Multi-Tenancy for Users within Organizations 

So far, we see multi-tenancy when the tenants are essentially the entire organization. However, organizations have users or groups of users. In more complex multi-tenancy implementations, data security needs to be implemented among groups of users like regions, departments, managerial levels, etc. In such a multi-level multi-tenant environment, each organization's users (or group of users) become sub-tenants. They also need access to the databases or tables in isolation or sharing mode. Here, rather than organizational context, one can also use custom user properties (or user contexts) with data source connection strings, security filters expressions, and/or dataset parameters & filters.

Conclusion

More often, modern SaaS applications implement a hybrid model for the multi-tenancy, a combination of the isolated and shared modes. The implementation of this model varies among SaaS providers. Wyn Enterprise can combine the multi-tenancy settings to implement the hybrid mode multi-tenant environment.

If you have hosted Wyn Enterprise as an embedded BI, you can also use the contexts from your custom implementation of the security provider for the data security and governance rules.