Access control is property-based and the properties are used to describe the parties involved in an access request. In this case the parties involved are the following:
- The User making the request
- The Environment the request is made from
- The Resource the request applies to
Each property is defined by a value in a so called property-value pair such as "group = Sales" or "resourcetype = App". Each request in turn includes the property-value pairs for the users, environments and resources involved in the request together with the action that the requester wants to perform on the resource, for example create, update, or delete.
Evaluating access using rules
You can create rules based on the property-value pairs. By this we mean that requests for an action on a resource is granted only if the property value of the requester matches the property-value conditions defined in a security rule for that resource.
In general a rule can read as a sentence:
"Allow the requester to [action] the [resource] provided that [conditions]."
Each rule must describe the action and the resource or resources the action should be applied to. If you don't define any rules for a resource then no users will have access to that resource.
Having received the request, the rule engine will evaluate the request against all rules that are applicable. Applicable rules are those that apply to the same resource type as the request. Each rule comes with a resource filter to save the rule engine from having to evaluate the request against all resources. Finally you can specify exactly which resource a rule applies to by providing resource property conditions in the condition.
The rule evaluation workflow
Example: One property-value pair in conditions:
For example, assume that you work in the sales department at your company and want to read the Quarterly results stream published by the financial department. In this case there is a rule on that stream that states that only users who belong to the Active Directory group finance are allowed to read that stream.
Translating this into a rule could look like this:
"Allow the user to [read] the [Quarterly results stream] provided that [group=finance]."
In this example the rule will evaluate to False, that is to say you do not have read access because group does not equal finance for this user. In practice you will not even see the stream icon.
The rule evaluation workflow is as follows:
- Request to [read] the [Quarterly results stream] sent by user
- The rule engine identifies which rules to evaluate the request against
- The request is evaluated by the rule engine
If any criteria is not met, you are not granted access
Example: More than one property-value pair in conditions:
The rule evaluation workflow example was basic in that it has one action on one resource with one condition. However, the strength of the Qlik Sense security rules is that you can apply several actions to multiple resources with different conditions in one rule. Looking at the Quarterly results example, we could extend the rule to provide read and update access to both the finance and the management departments using their Active Directory groups as input:
"Allow the user to read AND update the [Quarterly results stream] provided that group = finance OR group = management."
Predefined security rules in Qlik Sense
Qlik Sense is supplied with predefined sets of rules called ReadOnly and Default rules. These rules are supplied to make it possible for QMC administrators to maintain the Qlik Sense system and create, update and maintain security rules. ReadOnly rules are ones that are critical to the security and cannot be edited. Default rules can be edited to suit your company and system requirements.