ActiveReports Server: Introduction implementing to multi-tenant ad hoc reporting

While implementing ad hoc, self-service reporting in a multi-tenant environment, we aim to restrict access to underlying data from the database based on the organization (“tenant”) of the user who is logged into the system. This is a typical deployment scenario for Web-based solutions catering to multiple customers, each of whom has individual sets of data. There are many forms of multi-tenancy and the implementation varies by case depending on a number of factors. These architectures vary in degrees of data isolation from an extreme of completely 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. In this post we will cover multi-tenancy using both the Server and the Server Report Designer (for the models, etc). Although not covered explicitly here, Multi-tenancy is also possible in similar ways using Server Core with AR Developer licenses. ActiveReports Server’s approach to multi-tenancy is flexible enough to be compatible with various deployment scenarios. We will touch on various ways in which data is segregated in a multi-tenant deployment and how to use ActiveReports Server features to integrate with these environments. The key functional areas of ActiveReports Server in multi-tenant environments are security providers and security filters configured using the Administrator Dashboard. 

The Security Provider

The security provider acts as an authentication mechanism for ActiveReports Server. The key functions of the security provider are:

1. Authenticating the user who is logging into ActiveReports Server.
2. Providing details, based on the logged-in user, regarding Roles and any additional information that may be required by the database.

By default, ActiveReports Server has a security provider that authenticates users against the built-in user accounts added in the Administrator site. This layer of security can be extended by creating a custom security provider using the ISecurityProvider interface included in the SDK. This allows you to integrate ActiveReports Server with the proprietary authentication mechanism of the multi-tenant environment, without the need to replicate user information in multiple locations. With authentication, the custom security provider also identifies user-specific information about the person logging into the Report Designer. In a multi-tenant environment, along with the Roles that the user is in, these values passed in via the UserContext class could include information like the tenant ID, database connection properties, and any other information your custom security provider requires. The UserContext values transparently filter the data shown in reports when a user logs in. Similar to other role-based security models, Roles in ActiveReports Server represent a set of permissions to the available reports and logical data models. The custom security provider determines which roles the user is a member of and provides this information to ActiveReports Server, allowing the correct reports to be made available to the user. The custom security provider may also provide additional information regarding the user in the form of user context values such as user display name, E-mail address, department, etc. These can be used in security filters to fine tune what is available to the user within ActiveReports Server.

Multi-Tenancy in Shared Database Systems: Using Security Filters

In a multi-tenant shared database implementation, data is stored in the same table for all tenants. An identifier such as a tenant ID associates each row of data in the table to the appropriate tenant, so a method for row-level isolation of data is required to allow them to access information. Security filters in ActiveReports Server can be used to configure this kind of row-level security requirement. You can configure these in the data model for each entity that requires tenant-specific data isolation. In a multi-tenant environment, one of the user context values provided by the custom security provider could be the tenant ID. You can use this value in expressions you define in the Security Filter property of each entity that requires row-level filtering. The criteria you set for the security filter is a logical expression that depends on the way that the multi-tenant environment is configured to identify the records available to a user. Scenarios may be as simple as the tenant ID value or have varying degrees of complexity. Security filters are defined as part of the entity definition in the logical data model. They are transparent to the business user and ActiveReports Server applies them to all queries run on the database. Specify security filters for all entities that you want to filter based on the current tenant. You can reuse an existing filter expression in related entities, but you still configure each entity separately. This allows you to have entities and information that is constant for all tenants, such as lookup values, without the need to create multiple entities.

Multi-Tenancy in Isolated Database Systems: Dynamic Database Connection Strings

In a multi-tenant isolated database implementation, an additional level of isolation of tenant-specific information is used. In these deployments, each tenant has their own database, which may reside on the same database server or may be in physically different servers or server instances. In a logical data model, the connection string specifies the location of the database and the user credentials required for it. So for this kind of deployment, ActiveReports Server allows you to configure data model connection strings as dynamic values. You can also use special identifiers to plug in user context values from the security provider. For example, to specify a user context value called “UserContext.DBName” in the data model connection string, use “%UserContext.DBName%” where you would typically enter the static database name. ActiveReports Server substitutes this placeholder with the value from the user context when running queries to get data for reports.

Conclusion

As you can see, you can configure ActiveReports Server to work with various flavors of multi-tenant environments. This flexibility allows you to address the reporting needs of all of your tenants with one ActiveReports Server deployment. It also allows you to use the same data model across multiple tenants, which greatly reduces your maintenance cost during application upgrades. Similarly users from different tenants can use the same report to get information related only to their organization.