Skip to main content Skip to complementary content

Property-based access control

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.

A request containers Properties and Actions. Properties contains USER, ENVIRONMENT, RESOURCE. USER contains the following properties and values: name = MyName, userid = mne, group = Sales, etc. ENVIRONMENT contains the following properties and values: ip =, os = Windows, secureRequest = True. RESOURCE contains the following properties and values: name = MyApp, resourcettype = App, owner = MyName. REQUEST also contains the following Actions: create, update, delete, etc.

Access request

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.

Information noteYou are not required to provide conditions. However, not doing this will result in the rule applying to all users and/or resources.

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.

REQUEST contains Properties and Actions. REQUEST connects to RULE ENGINE, which contains Identify applicable rules and Evaluate request vs rule. RULE ENGINE has an arrow pointing back to REQUEST, but with an "Access not granted" in the middle of the arrow. Properties inside of REQUESt contains USER and RESOURCE boxes. The USER box contains the following properties and values: name = MyName, userid = mne, group = Sales. The RESOURCE box contains the following properties and values: name = Quarterly results, resourcettype = Stream. Below the Properties container, there is an Actions container which contains a read box. Identify applicable rules inside of RULE ENGINE contains RULE, which contains the following rules: Allow Read, On resource Quarterly results stream, Provided that group = finance. Identify applicable rules connects to Evaluate request vs rule inside. Evaluate request vs rule contains three colums and four rows. The first is: action = Read, checkmark, action = Read. The second row is: resource = Quarterly results, checkmark, resource = Quarterly results. The third row is: resourcetype = stream, checkmark, resourcetype = stream. The third row is: group = sales, X mark, group = finance.

Rule evaluation

The rule evaluation workflow is as follows: 

  1. Request to [read] the [Quarterly results stream] sent by user
  2. The rule engine identifies which rules to evaluate the request against
  3. The request is evaluated by the rule engine
  4. 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.

Information noteIf you edit a default rule, that is, a rule that is supplied with Qlik Sense, the rule type definition changes from Default to Custom. Keep in mind that changing a default rule, or adding a new rule that affects the default rules, may cause unexpected behavior in Qlik Sense. Use the rule preview feature to check rule behavior before implementing changes to default rules. Remember that only read only and default rules are automatically updated when you upgrade to a new Qlik Sense version.

Did this page help you?

If you find any issues with this page or its content – a typo, a missing step, or a technical error – let us know how we can improve!