19 September, 2018
A security in QlikView can be set up in two different ways:
-Built into the QlikView document script
-Set up through the use of QlikView Publisher.
Authentication is any process by which it is verified that someone is who they claim they are. QlikView can either let the Windows operating system do the authentication, or prompt for a User ID and Password (different from the Windows User ID and Password) or use the QlikView license key as a simple authentication method.
Authorization is finding out if the person, once identified, is permitted to have the resource. QlikView can either let the Windows operating system do the authorization or do the authorization itself. For the latter, a security table must be built into the script.
If the QlikView Publisher is set up to handle security, then each QlikView file will be split up into several files, each containing the data pertaining to the relevant user or user group.
These files will be stored in folders with the correct OS security settings, i.e. QlikView lets the operating system handle Authentication and Authorization.
There is, however, no security built into the file itself, so there is no protection on a downloaded file.
The file sizes will usually be smaller, since one single file will be split into several and the user only opens the file with his own data.
However, this also means that a QlikView Server can potentially use more memory than if all data are kept in one file, since several files containing the same data sometimes will be loaded.
Security Using the Section Access in the QlikView Script
If the Section Access in the QlikView script is set up to handle security, then one single file can be made to hold the data for a number of users or user groups.
QlikView will use the information in the Section Access for Authentication and Authorization and dynamically reduce the data, so that the user only sees his own data.
The security is built into the file itself, so also a downloaded file is to some extent protected.
However, if the security demands are high, downloads of files and offline use should be prevented. The files should be published by the QlikView Server only.
Since all data are kept in one file, the size of this file can potentially be very large.
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”normal” data must be put in a different section, initiated by the statement section application.
Load * inline
[ACCESS, USERID, PASSWORD
ADMIN, A, X
USER, U ,Y ];
Load... ... from... ...
Access Levels in Section Access
Access to QlikView documents 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 access level is assigned, the user cannot open the QlikView document.
A person with ADMIN access can change everything in the document. Using the Security page in the Document Properties and Sheet Properties dialogs, a person with ADMIN access can limit the users’ possibilities of modifying the document. A person with USER privileges cannot access the Security pages.
ADMIN rights are only relevant for local documents! Documents opened on a Server are always accessed with USER rights.
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 PASSWORD, 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 are described below.
ACCESS: A field that defines what access the corresponding user should have
USERID: A field that should contain an accepted user ID. QlikView will prompt for a User ID and compare it to the value in this field. This user ID is not the same as the Windows user ID.
PASSWORD: A field that should contain an accepted password. QlikView will prompt for a Password and compare it to the value in this field. This password is not the same as the Windows password.
SERIAL: A field that should contain a number corresponding to the QlikView serial number. Example: 4900 2394 7113 7304 QlikView will check the serial number of the user and compare it to the value in this field.
NTNAME: A field that should contain a string corresponding to a Windows NT Domain user name or group name. QlikView will fetch the logon information from the OS and compare it to the value in this field.
NTDOMAINSID: A field that should contain a string corresponding to a Windows NT Domain SID. Example: S-1-5-21-125976590-4672381061092489882 QlikView will fetch the logon information from the OS and compare it to the value in this field.
NTSID: A field that should contain a Windows NT SID. Example: S-15-21-125976590-467238106-1092489882-1378 QlikView will fetch the logon information from the OS and compare it to the value in this field.
OMIT: A field that should contain the field that should be omitted for this specific user. Wildcards may be used and the field may be empty. A facile way of doing this is to use a subfield.
Should not apply OMIT on key fields, as this will change the underlying data structure. This may create logical islands and calculation inconsistencies.
If the User ID and/or the Password are not entered correctly within three attempts the entire log-on procedure must be repeated.
All the fields listed in Load or Select statements in the section access must be written in UPPER CASE. Any field name containing lower case letters in the database should be converted to upper case using the upper function, before being read by the Load or Select statement.
However the user ID and the password entered by the end-user opening the QlikView documents are case insensitive When loading data from a QVD file, the use of the upper function will slow down the loading speed.
Restrictions on QlikView Functionality
The controls found on the Document Properties: Security page and the Sheet Properties: Security page make it possible to disallow the access to certain menu items and prohibit changes in the layout. If these settings are to be used as a truly protective measure, it is important that the document users are logged in as USER. Anyone logged in as ADMIN can change the security settings at any time.
A user that has opened the document with USER rights does not have the Security pages in the Properties dialogs.
Dynamic Data Reduction
QlikView and QlikView Server support a feature by which some of the data in a document can be hidden from the user based on the section access login.
-Fields (columns) can be hidden by the use of 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/excluded is controlled by means of having one or more fields with common names in section access and section application. After user login QlikView will attempt to copy the selections in fields in section access to any fields in section application with exactly the same field names (the field names must be written in UPPER CASE). After the selections have been made, QlikView will permanently hide all data excluded by these selections from the user
In order for this procedure to take place, the option Initial Data Reduction Based on Section Access on the Document Properties: Opening page must be selected. If this feature is used in documents that are to be distributed by other means than via QlikView Server, the option Prohibit Binary Load on the same page of the Document Properties must be selected in order to maintain data protection.
All field names used in the transfer described above and all field values in these fields must be upper case, since all field names and field values are by default converted to upper case in section access.