Managing security with section access

You can use section access in the data load script to handle security. In this way, a single file can be used to hold the data for a number of users or user groups. Qlik Sense uses the information in the section access for authentication and authorization, and dynamically reduces the data, so that users only see their own data.

Note: User groups are not supported in Kubernetes.

The security is built into the file itself, which means a downloaded file is also protected, to some extent. However, if security demands are high, downloading of files and offline use should be prevented, and files should be published by the Qlik Sense server only. As all data is kept in one file, the size of this file can potentially be very large.

Warning:

To avoid exposing restricted data, remove all attached files with section access settings before publishing the app.

Attached files are included when the app is published. If the published app is copied, the attached files are included in the copy. However, if section access restrictions have been applied to the attached data files, the section access settings are not retained when the files are copied, so users of the copied app will be able to see all the data in the attached files.

Warning: A snapshot shows data according to the access rights of the user who takes the snapshot, and the snapshot can then be shared in a story. However, when users return to a visualization from a story to see the live data in the app, they are restricted by their own access rights.
Warning:

You must not assign colors to master dimension values if you use section access or work with sensitive data because the values may be exposed.

Sections in the script

Access control is managed through one or several security tables loaded in the same way that Qlik Sense normally loads data. This makes it possible to store these tables in a normal database. The script statements managing the security tables are given within the access section, which in the script is initiated by the statement Section Access.

If an access section is defined in the script, the part of the script loading the app data must be put in a different section, initiated by the statement Section Application.

Example:  

Section Access; LOAD * inline [ ACCESS, USERID USER, User_ID ]; Section Application; LOAD... ... from... ...

Section access system fields

The access levels are assigned to users in one or several tables loaded within the section access. These tables can contain several different user-specific system fields, typically USERID, and the field defining the access level, ACCESS. All section access system fields will be used for authentication or authorization. The full set of section access system fields is described below.

ACCESS

Defines what access the corresponding user should have.

Access to Qlik Sense apps can be authorized for specified users or groups of users. In the security table, users can be assigned to the access levels ADMIN or USER. If no valid access level is assigned, the user cannot open the app.

A person with ADMIN privileges has access to all data in the app. A person with USER privileges can only access data as defined in the security table.

If section access is used in an on-demand app generation (ODAG) scenario in the template app, the INTERNAL\SA_API user must be included as ADMIN in the section access table. For example:

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, INTERNAL\SA_API ];

USERID

Contains a string corresponding to a Qlik Sense user name. Qlik Sense will get the login information from the proxy and compare it to the value in this field.

GROUP

Contains a string corresponding to a group in Qlik Sense. Qlik Sense will resolve the user supplied by the proxy against this group.

Note: When you use groups to reduce data and want to Qlik Management Console, the INTERNAL\SA_SCHEDULER account user is still required.

OMIT

Contains the name of the field that is to be omitted for this specific user. Wildcards may be used and the field may be empty. An easy way of doing this is to use a sub field.

Note: We recommend that you do not apply OMIT on key fields. Key fields that are omitted are visible in the data model viewer, but the content is not available, which can be confusing for a user. Additionally, applying OMIT on fields that are used in a visualization can result in an incomplete visualization for users that do not have access to the omitted fields.

Qlik Sense will compare the user supplied by the proxy with UserID and resolve the user against groups in the table. If the user belongs to a group that is allowed access, or the user matches, they will get access to the app.

Note:

If you have locked yourself out of an app by setting section access, you can open the app without data, and edit the access section in the data load script. This requires that you have access to edit and reload the data load script.

For more information, see Opening an app without data.

As the same internal logic that is the hallmark of Qlik Sense is also used in the access section, the security fields can be put in different tables. All the fields listed in LOAD or SELECT statements in the section access must be written in UPPER CASE. Convert any field name containing lower case letters in the database to upper case using the Upper function before reading the field by the LOAD or SELECT statement.

For more information, see Upper - script and chart function.

A wildcard, *, is interpreted as all (listed) values of this field, that is. a value listed elsewhere in this table. If used in one of the system fields (USERID, GROUP) in a table loaded in the access section of the script, it is interpreted as all (also not listed) possible values of this field.

Note: When loading data from a QVD file, the use of the upper function will slow down the loading speed.
Note: If you have enabled section access, you cannot use the section access system field names listed here as field names in your data model.

Example:

In this example, only users in the finance group can open the document.

Access to document
Access Group
USER Finance

Dynamic data reduction

Qlik Sense supports dynamic data reduction, in which some of the data in an app can be hidden from a user, based on the section access login:

  • Fields (columns) can be hidden by using the system field OMIT.
  • Records (rows) can be hidden by linking the section access data with the real data: The selection of values to be shown or excluded is controlled by having one or more fields with common names in section access and section application. After user login, Qlik Sense will attempt to match the selections in fields in the section access to any fields in the section application with exactly the same field names (the field names must be written in UPPER CASE). After the selections have been made, Qlik Sense will permanently hide all data excluded by these selections from the user.
Note: All field names used in the transfer described above and all field values in these fields must be upper case, because all field names and field values are, by default, converted to upper case in section access.
Note: If you want to enable reload of the script in a Qlik Management Console task, the INTERNAL\SA_SCHEDULER account user with ADMIN access is required.

Example: Data reduction based on user id

Section Access; LOAD * inline [ ACCESS, USERID, REDUCTION, OMIT USER, AD_DOMAIN\ADMIN, *, USER, AD_DOMAIN\A, 1, USER, AD_DOMAIN\B, 2, NUM USER, AD_DOMAIN\C, 3, ALPHA ADMIN, INTERNAL\SA_SCHEDULER, *, ]; section application; T1: LOAD *, NUM AS REDUCTION; LOAD Chr( RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

The field REDUCTION (upper case) now exists in both section access and section application (all field values are also upper case). The two fields would normally be totally different and separated, but using section access, these fields are linked and the number of records displayed to the user is reduced.

The field OMIT, in section access, defines the fields that should be hidden from the user.

The result will be:

  • User ADMIN can see all fields and only those records other users can see in this example when REDUCTION is 1,2, or 3.
  • User A can see all fields, but only those records associated to REDUCTION=1.
  • User B can see all fields except NUM, and only those records associated to REDUCTION=2.
  • User C can see all fields except ALPHA, and only those records associated to REDUCTION=3.

Example: Data reduction based on user groups

Section Access; LOAD * inline [ ACCESS, USERID, GROUP, REDUCTION, OMIT USER, *, ADMIN, *, USER, *, A, 1, USER, *, B, 2, NUM USER, *, C, 3, ALPHA USER, *, GROUP1, 3, ADMIN, INTERNAL\SA_SCHEDULER, *, *, ]; section application; T1: LOAD *, NUM AS REDUCTION; LOAD Chr( RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

The result will be:

  • Users belonging to the ADMIN group are allowed to see all data and all fields.
  • Users belonging to the A group are allowed to see data associated to REDUCTION=1 across all fields.
  • Users belonging to the B group are allowed to see data associated to REDUCTION=2, but not in the NUM field
  • Users belonging to the C group are allowed to see data associated to REDUCTION=3, but not in the ALPHA field
  • Users belonging to the GROUP1 group are allowed to see data associated to REDUCTION=3 across all fields
  • The user INTERNAL\SA_SCHEDULER does not to belong to any groups but is allowed to see all data in all fields.

    Note:

    The wildcard, character *, in this row refers only to all values within the section access table. If there are values in the section application that are not available in the REDUCTION field in section access, they will be reduced.

Inherited access restrictions

Note: This functionality is not available in Kubernetes.

A binary load will cause the access restrictions to be inherited by the new Qlik Sense app.

Did this information help you?

Thanks for letting us know. Is there anything you'd like to tell us about this topic?

Can you tell us why it did not help you and how we can improve it?