Incorta allows you to restrict user data access in the Incorta Direct Data Platform using:
These concepts allow you to share the same dashboard among different users. For example, a sales representative and a VP of Sales could view the same dashboard, but would see different views of the data, including different rows and different column values.
We recommend that you be familiar with these concepts in Incorta Docs.
Applies to all Incorta versions, however as a growing feature, there are additional options as well as syntax enforcement in release 4.8 and up.
A session variable is used to establish a user context throughout the user session while a user is accessing Incorta dashboards. It can provide users a personalized view of the content. When a session variable is specific to a user and is used as a data filter, it can be used to apply data security.
The $user variable is a system variable that is available from Incorta and does not have to be initialized and defined in the session variable page. The $user variable returns the value “Login Name” of the user that is currently logged in. The Login Name is entered when the user is created by the Incorta User Manager or administrator. When Incorta users are created via directory synchronization, the login name is determined by the mapping logic defined as part of the Directory synchronization property file.
Session variables can be used in other session variables and can be chained as far as needed. When the $user variable is being used, the session variable becomes specific to a user. Using session variables to provide personalized / secured data views is recommended over creating separate content for different users.
Incorta supports the use of both external and internal session variables. Initializing an internal session variable requires the data to be loaded to Incorta first which requires that a schema table be created for that purpose. You will have to wait for a data load to complete before initializing with the most up to date value but internal variables are considered more reliable as they are not affected by network issues or external system availability. If there is no real-time refresh requirement for the session variable, Incorta recommends using internal variable as, after the initial load of the source table, they will always have a value.
External session variables are initialized in real time the first time that they are accessed from a dashboard during an Incorta user session. Incorta executes a SQL statement to fetch the value directly from an external database source such as Oracle or MySQL. Once the external variable is fetched from the source, its value remains unchanged throughout the user session. If the external system is not available, and the session variable is used as a data security filter, the user will not be able to access the secured data. If data security is a strong concern or security rule change frequently, using external variables is beneficial as they are populated in real time. When using external session variables, It is important to make sure that you have sufficient connection pool available and that both a reliable network and data source exists.
A runtime security filter is a filter expression that the Analytics Service applies when a user accesses an in-memory physical schema table, materialized view, Incorta Analyzer Table, or Incorta SQL Table. Typically, the purpose of a runtime security filter is to apply a filter expression that implements Row Level Security (RLS) using a form of Role-Based Access Control (RBAC).
There are some business sensitive columns that only certain users should have access to. For example, you may have salary information in your data that only executives or users at a certain management level or above should be able to see. All other dashboard users should not see the actual values.
You can solve this problem by applying data masking, also known as column level security, to your sensitive data columns. You can implement data masking in Incorta by using session variables and formulas. First, create a session variable to identify the groups to which the logged in user belongs. Next, create a formula with the sensitive column and the rule to apply for insight and dashboard consumption. Publish the formula column, not the original data column, to the appropriate business view and grant access to it not the original table.
Here is a sample formula for the use case referenced above.
IF($executive_managerial_group = 'Y', HR.Employees.Salary, '******')