In cloud architecture, multi-tenancy refers to a design concept where a single instance of a program supports several users, or tenants. As hosting and administrative tasks are centralized, this method simplifies maintenance, reduces expenses, and maximizes resource use.
‘Database Per Tenant’ and ‘Shared Database’ are two popular variations of multi-tenant architecture:
Database per Tenant: Under this arrangement, every tenant has a personal database. The entire inaccessibility of one tenant’s data to others is ensured by this separation, which offers a high degree of data isolation and security. It works especially well in situations when tenants have strict needs for data protection or where their size justifies the allocation of certain resources. However, as the number of databases grows with each new tenant, managing this strategy at scale may become costly and difficult.
Shared Database: On the other hand, several tenants share a single database under the shared database paradigm. This strategy frequently uses methods like appending a tenant ID to every record or utilizing different schemas for every tenant inside the same database in order to preserve data isolation. This concept is easier to administer and more economical, particularly for a large number of tiny renters. If not properly handled, it may cause problems with maintaining strong data segregation and may result in performance problems.
We looked at utilizing PostgreSQL and.NET to set up a multi-tenant environment in an earlier article, with an emphasis on the Database Per Tenant paradigm. This time, our emphasis is on using Row Level Security (RLS) in PostgreSQL to provide fine-grained tenant isolation at the entity level. We’ll go into the nuances of RLS and show you how to incorporate it into your application layer so that developers can work with it without any problems. This talk aims to preserve the developer-friendly approach we’ve stressed throughout our series while improving our multi-tenant architecture’s security and efficiency.
In this article, we’re diving into the practical aspects of integrating Fluent NHibernate, PostgreSQL, and Fluent Migrator in a .NET Core API solution, tailored for a multi-tenant environment. We’ll walk through the following critical steps to build a robust foundation for your application:
- Defining Our Base Entity: We’ll start by outlining how to define our base entity using Fluent NHibernate, setting the stage for a clean and efficient mapping process.
- Configuring Data Tables: Next, we’ll leverage Fluent Migrator to create and configure our data tables. This step is crucial for ensuring the structural integrity and scalability of our database.
- Implementing .NET Middleware: To efficiently capture the Tenant ID, we’ll delve into the implementation of a .NET middleware. This will play a pivotal role in maintaining tenant context throughout the application lifecycle.
- Extending NHibernate for Tenant ID: Finally, we’ll explore how to extend NHibernate to incorporate Tenant ID effectively, ensuring that our data access layer remains tenant-aware and secure.
Defining Our Base Entity
Our application’s abstract Entity class contains the essential components of our database design. This class provides the basic fields required by our multi-tenant architecture, serving as the underlying blueprint for our database entities.
- Vital Fields: The ID and the Tenant ID are the two vital fields that every entity in our database inherits from this base class. Each record is uniquely identified by the ID, which guarantees distinctness and simple retrieval. For our multi-tenant architecture, the Tenant ID is essential since it links each record to a particular tenant, which makes data segmentation easier.
- Tenant ID: We strategically use it by attributing it so that it serves its purpose in the database and doesn’t appear in our API answers. This strategy is especially crucial in cases where we maintain the Tenant ID as an internal component of our database schema and do not use Data Transfer Objects (DTOs) for API responses.
Configuring Data Tables
We will be improving our multi-tenant system by moving forward with the Books entity. We will go over how to use Fluent Migrator to write a database migration that specifically takes advantage of Row Level Security (RLS) in PostgreSQL.
- Turning on Row Level Security (RLS): First, we activate RLS for the Books table. It’s crucial to remember that RLS is a PostgreSQL-only feature. There may be differences in the availability and implementation of identical functionalities if you are using a different database system. In order to maintain the security and tenant-specificity of our data, RLS activation is a vital step.
- Creating a Security Policy: The next step is to create a security policy on the Books table after RLS has been enabled. This policy associates the tenant ID in each entry of the Books table with the current context of our application’s ‘app.current_tenant’ property.
- Implementation of the Policy: The applied policy essentially stipulates that a tenant’s ID must match the ‘app.current_tenant’ option in order for any record in the Books table to be visible or editable. In accordance with our multi-tenant architecture, this method guarantees that tenants can only interact with their data.
I suggest looking through the PostgreSQL documentation on Row Level Security settings for more specific implementation suggestions and in-depth details.
Implementing .NET Middleware
Accurately determining and making use of the Tenant ID linked to every user request is essential to administering a multi-tenant environment. While there are a number of ways to accomplish this, we’ll concentrate on one in particular: retrieving the Tenant ID from the HTTP context of the logged-in user.
Using the HTTP Context as a Source: We make advantage of the data included in the HTTP context, namely examining the information linked to the currently logged-in user. This is a simple and efficient way that gives us the Tenant ID we need to customize our application’s user interface and data access.
Tenant Service Integration in.NET Core: We include the Tenant Service as a Scoped Service inside the.NET Core Builder Services in order to smoothly incorporate this feature. We can ensure that every action taken within the scope of a request is pertinent to the identified tenant by using this integration to preserve the Tenant ID throughout the request lifetime.
Extending NHibernate for Tenant ID
Our next crucial step is to set the ‘app.current_tenant’ before query execution after creating our data table with a tenant isolation policy and successfully getting the Tenant ID from the User HTTP Context of the current API call. In order to guarantee that every transaction is suitably tenant-scoped, this setting is essential.
NHibernate querying: We do not write direct queries to the database backend in our application. Rather, we utilize NHibernate’s power. By abstracting the complexity of straight SQL queries and guaranteeing a more manageable codebase, NHibernate makes database querying easier.
Using NHibernate Interceptors: We use NHibernate Session Factory interceptors to incorporate the Tenant ID into our NHibernate workflow. The purpose of these interceptors is to preemptively set the ‘app.current_tenant’ property before to the start of each and every NHibernate transaction.
An important part of our multi-tenant architecture is the integration of Tenant ID with NHibernate queries via interceptors. By guaranteeing that each data exchange is tenant-specific, it upholds stringent data integrity and isolation throughout our application. We also greatly improve the developer experience by automating this process within the NHibernate framework, which speeds up the creation and upkeep of our multi-tenant system.
The Tenant Interceptor serves two purposes in our multi-tenant application, greatly improving the effectiveness and dependability of our tenant-specific processes.
Before Queries, setting ‘app.current_tenant’: Before running any queries, the Tenant Interceptor’s first and most important task is to set ‘app.current_tenant’ to the correct Tenant ID. This crucial step makes sure that our Row Level Security policies are effectively implemented, limiting the designated tenant’s access to data. We guarantee consistent implementation of our isolation policies across all database transactions by automatically setting this value at the query level.
Automating the Assignment of Tenant IDs during Entity Creation: Tenant Interceptor overrides the OnSave method, thus streamlining our development process. The purpose of this override is to automatically assign the Tenant ID to newly created entities. By doing this, we remove the laborious task of manually verifying that the correct Tenant ID is issued to each newly created entity for developers. By making entity formation simpler, this automation not only lowers the possibility of errors but also expedites the development process.
In conclusion, we have effectively established a multi-tenant system with PostgreSQL, NHibernate, and.NET Core. Important highlights include of:
- PostgreSQL Row Level Security implementation for data isolation.
- Tenant IDs are efficiently captured from the HTTP context.
- Making use of NHibernate’s interceptors to create entities and execute queries with ease.
