Once a user has been authenticated (that is, the system knows who the user is), the first step in assigning the security privileges has been completed. The second step is to understand the authority or access rights that the user has to applications, data, or both. This step is referred to as Authorization. At a fundamental level, an administrator populates an Access Control List (ACL) with a list of users and/or groups and what they are to have access to. When the time comes for a user to request access, the system looks up the authenticated identity of the user in the ACL and verifies if the administrator has granted the user enough privileges to do so.
Direct access to a QlikView document using QlikView Desktop is always governed by the Windows NTFS file security. Access to the web-based QlikView Management Console (QMC) is restricted to Windows users that are members of a particular local Windows group.
Document Level Authorization
Once a user has been authenticated, QlikView Server typically handles authorization on its own. QlikView Server provides the choice between storing the ACL information as Windows NTFS privileges (applicable only when the user is authenticated using a Windows user identity) or by storing the ACL information in the internal repository, Document Metadata Service (DMS), in QlikView. The choice of NTFS or DMS affects the access to all documents in QlikView Server.
NTFS vs. DMS
QlikView Server can use the NTFS privileges of the Windows file system to store authorization information. When in NTFS authorization mode, QlikView Server controls access to a given QlikView document by determining if the authenticated user has NTFS privileges to the underlying QlikView document file (.qvw or .qvf). This is based on the operating system privileges and Windows NTFS is used for the ACL. The privileges of the authenticated user are configured by a server administrator using standard Windows Explorer functionality via directory properties options.
As an alternative to Windows NTFS, QlikView can use its own ACL, DMS. Unlike NTFS, this allows non-Windows users and groups to be authorized to access applications and data. DMS integrates fully with the existing Directory Service Provider (for example, Active Directory, other LDAP) where Group Membership has been recorded – this is a mechanism by which QlikView Server can re-use existing enterprise accounts and group structures. The permitted users or groups are recorded in a meta file that resides next to the QlikView document, and it is managed using QMC.
NTFS is the default document authorization model, suitable when all users and groups are identified in Active Directory or locally on the QlikView Server host. The NTFS permissions may be inherited from the directory that the QlikView documents are in, or may be assigned using QlikView Publisher distribution tasks.
DMS is required when the authenticated user identity is not a Windows user account. The DMS permissions are explicitly assigned using QMC, or may be assigned using QlikView Publisher distribution tasks.
Data Level Authorization
Data level authorization allows access to be granted or denied on a document level and even to specific data in a document.
There are two types of data level authorizations:
- Dynamic data reduction: Determines if the user is allowed to view the data when the user tries to access it.
- Static data reduction: Performed by QlikView Publisher, determines if the user is allowed to view the data when it is prepared for the user.
Static and dynamic reduction of data can be used on its own, but can also be combined to deliver data level authorization.
Dynamic Data Reduction
Dynamic data reduction is done in QlikView using the concept of Section Access, which is part of the QlikView document.
Section Access Management is configured in the QlikView Management Console (QMC). For information, see the QMC help.
Static Data Reduction
For larger deployments and/or those in need of centralized control of authorization capabilities, QlikView Server/Publisher are used. Departments or functions often have a “master” application that contains all relevant data covering all analysis needs, and this master document needs to be separated (“reduced”) according to the needs and access privileges of the intended audience. QlikView Publisher reloads the QlikView document with available data, refreshes the Section Access tables, and splits the large QlikView document into smaller documents based on values in a particular field.
This “reduction and distribution” allows for a file containing many data fields to be broken up by the contents of a field and distributed to authorized users or groups according to their access privileges.
One of the benefits of reducing and distributing source files in this manner is that the documents that are created in this process contain no explicit reference to the source data (for example, a database connection string) in their script environments. Therefore, if a user interacts with the document via QlikView Desktop, the user cannot see the location of the source data. All of the data pertinent to the user needs is contained in the document.
An administrator can use QMC to create tasks on source .qvw, .qvfor .qvd files to accomplish this. At a basic level, the steps are as follows:
An administrator can use QMC to create tasks on source .qvw, .qvfor .qvd files to accomplish this. At a basic level, the steps are as follows:
- On the source document (either .qvw, .qvf or .qvd), apply the data reduction criteria (for example, choose the field name on which to reduce the data).
- Apply the distribution criteria to the newly created (reduced) files:
- Assign the authorization privileges using either DMS or NTFS ACLs.
- Choose the type of distribution (for example, .qvw or .qvf files or .pdf report).
- Choose the location for the newly created files.
- Apply the notification criteria for the completion of the task (for example, e-mail notification).
The newly created files only contain the data that the user or group is authorized to see, since the data has been “reduced” from the master document in accordance to the reduction criteria. This is why the process is termed “Static Data Reduction”. Hence, there is no risk of an unauthorized person viewing data, since only authorized data exists in each file.
