cancel
Showing results for 
Search instead for 
Did you mean: 
RichC
Employee
Employee

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

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 as needed 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.

  • 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.

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, '******')

 

Related Material

Best Practices Index
Best Practices

Just here to browse knowledge? This might help!

Contributors
Version history
Last update:
‎10-04-2022 07:35 AM
Updated by: