Introduction
Incorta allows you to restrict user data access in the Incorta Direct Data Platform using:
- Session variables
- Runtime security filters
- Data masking
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.
What you need to know before reading this article
We recommend that you be familiar with these concepts in Incorta Docs.
Applies to
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.
Let's Go
Session Variables
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.
Session Variable Use Cases
- Current Period: Users would like to see the data in the current period by default and will switch to a prior period only when necessary. A session variable is created to default the Current Period.
- Currency Conversion: A presentation variable is used to select the user's local currency code which is then used to find the appropriate conversion rate so that amounts are displayed in that currency. Users would like to see amounts in the currency where the division is located. A session variable can be created that uses the user profile to find the logged in user's division the currency used by the division. The session variable is then used as a default value in the presentation variable. A runtime security filter enforces data security at the row level. By using a session variable that is initialized based on the $user system variable, it is possible to limit data access by user.
- Data Security: Dashboard applied filters and insight filters are filters that are applied by analyst users to limit the data available in a dashboard or in a specific insight. By using user specific session variables, it is possible to provide a personalized view of the data on a dashboard and thus introduce data security at the dashboard level. Please note that the difference between implementing data security using runtime security filters and implementing it using an applied filter or an insight filter is that runtime security enforces secured data access to analyst users as well. Note that if a user has an analyst role and has privileges to make a copy of a dashboard and customize the dashboard, dashboard filters and insight filters can be easily removed and thus cannot be used to provide truly secure data access.
Runtime Security Filter
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).
Data Masking (Column-Level Security)
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, '******')
Related Material
.png "Employee"){kind=icon}
