This section explains the concept of security rules in Qlik Sense
Before you can use the Qlik Sense system, in most cases you want to know who the user is, we call this authentication.
The next step is that based on this userId you want to assign the user access rights, we call this authorization. Both developers and users communicate with Sense via the Proxy (see this as a webserver which performs the authentication step: who are you?).
After the authentication (who are you?) you need to think how you want to integrate the authorization (what can you do and see?). The keys you want to protect in Sense are called resources. Example resources are
In the client side, called the hub context:
- Streams
- Apps
- Objects inside an app
- Sheets
- Stories
- Script
- Datamodel viewer
In the admin side, called the management console (QMC) context
- Reload tasks
- Security configuration
- Apps
- Streams
- Users
There is no mandatory structure you have to follow in Sense. Qlik have designed a very flexible approach in which each "thing" in Sense is a resource. And if you want to "use" it you need to have a "key" that allows you to access that resource. In Sense, security rules protects the resources above, and it has the following logic:
In other words: a. If you want to do/see a resource b. You need at least 1 rule that evaluates to true c. Note: that this rule must provide access (resource filter) to all resources you need. If you want to see a chart, you need access to
- The stream
- The app
- The app.object
Example Admin 1 If your Active Directory group = Admin Then you are allowed to access all resources in the context of the QMC
Example End user 1 If your Active Directory group not equal to Admin Then you are allowed to access all resources in the context of the Hub
Lets illustrate this with the example of a city (a Sense server), it consists of
- streets (streams) which are used to
- group houses (apps), and a
- house consists of rooms (app.objects). Most people can only enter 1 house and all rooms. But in order to arrive at your room, you will have to drive though your street, open the house and enter your room.
You always need access to a stream before you can open the app, or view the resources inside an app:
- Stream: The highest level is the stream (e.g. a street), once you are in the street you can see
- App: The apps (the houses), once you enter a house you can see
- App.object: The app.objects (the rooms) like sheets, stories, script, database connections etc.
Import to remember: If you want to see a chart, you always need to create one or more security rules that together provide access to all the above resources. (stream, app, app.object)
Each resources knows always who its parent is. So you can make a security rule that says
- If the user tries to access a Stream:
- The name of the resource (in this case a stream) = (must equal) the name of the group of the user
- Then: you are allowed to see me
Now the user is authorized to see the stream. The next step is to grant him access to the app and app.object with this rule:
- If the user tries to access an app or the contents of an app (e.g. sheet)
- If you have access to my parent (has privilege)
- Then: you are allowed to see me
Sense security is based on Attribute Based Access Control ABAC. Each time a user requests access to a resource, Qlik Sense evaluates the request against the security rules in the Qlik Sense system. If at least one rule evaluates to True then Qlik Sense will provide the user with access according to the conditions and actions described in the security rule. If no rules evaluate to True then the user will be denied access. The fact that Qlik Sense security rules are property-based makes Qlik Sense very scalable as you can build rules based on properties that apply to groups of users. In most BI systems you need to create a role for each organizational value (Spain, France etc.), this is not needed with Sense. Qlik Sense just use a variable to variable comparison: e.g. If your Active directory group (or group provided by ticket/SAML) matches some property of the stream/dashboard you are allowed access.
If you don't have a key you won't get in, same like your house. If you have a key you can enter your house, and all rooms inside it. (Access to stream, Yes? Ok, than you might see all the dashboards)
So for Qlik Sense, if you have access to a stream maybe you want to show the user all dashboards inside the stream. In this way you keep the security concept very simple and effective. As a starting point it is recommended to give each department (HR, Finance) or customer (Customer A, Customer B) its own stream.
So Qlik Sense can give users access to a dashboard, and define whether he/she can use/edit/create Sheets, Stories, bookmarks etc. For example, if the user does not have access, that is a security rule that evaluates to true, he/she won't see the edit or bookmark button in Sense.
Inside of Qlik Sense, user access is proscribed by the security rules which are configured in the deployment. When designing a security rule framework, it is important to understand the hierarchical relationships between different resource filters in order to ensure that the rule performs as intended.
Consider the follwing -
As illustrated above. Apps are in Streams. This means that you can use inheritance to cascade the intended action from the action assigned at the Stream level. This is used in this portion of the default Stream security rule:
(resource.resourcetype = "App" and resource.stream.HasPrivilege("read"))
The meaning of this condition is that the action will be applied to Apps where the user has read rights to the stream.
The same hierarchy exists in Apps <> App.Objects. App.Objects belong to apps and thus you can inherit rights from the App or Stream level. This is used in this portion of the default Stream security rule:
((resource.resourcetype = "App.Object" and resource.published ="true" and resource.objectType != "app_appscript"
and resource.objectType != "loadmodel") and resource.app.stream.HasPrivilege("read"))
The meaning of this condition is that the action will be applied to an App's Objects where the object is a. published and b. not an app_appscript or loadmodel type of App.Object when the user has read rights on the stream.
As illustrated above, Tasks are applied to Apps. This means that you can use inheritance to cascade the intended action from the action assigned at the App level. For example:
Filter: ReloadTask*
Action: Read, Update, Delete
Condition: ((user.name="TaskAdmin"))and (resource.App.HasPrivilege("read"))
In this rule, the user with the name TaskAdmin is able to read / update / delete all tasks which are associated with Apps which they already have Read rights to. Note: As of Qlik Sense April 2018, there is no logical relationship between tasks and triggers. So an administrator cannot use inheritance for this resource type.