When comparing Qlik Sense to QlikView, the most obvious differences are on the front-end, with its completely overhauled and fully responsive design. Other major differences are the server-based development, the use of Master Items and the shift towards APIs, mashups, extensions and widgets.

Somewhat less prominent, though very deserving of your attention, is the security model in Qlik Sense. This has a completely new approach compared to QlikView, and you can pretty much create endless variations. Rather than hacking stuff together and hoping it works, my colleague Rik and I recently decided to take a more structured approach and do some R&D on Sense security rules. Our goal was to gain more understanding of security in Sense, develop methods for gathering and modeling security requirements and to design reference patterns for common implementation scenarios.

We will be sharing some of the methods and patterns that we came up with in an upcoming white paper. In the mean time, I’d like to share with you some of the little interesting, strange and otherwise noteworthy things that we found. These range from basic to slightly obscure, but all should hopefully help you get more understanding of Qlik Sense security rules. Let’s start with noting that the approach in Sense is totally different than it was in QlikView…

The ABAC-approach
In Qlik Sense, security works via Attribute Based Access Control. This, in short, means that a user gains access to any part of the environment through the use of security rules (policies)  that combine attributes. These rules can use any type of attribute: derived from the system or created by the user (custom properties). These attributes may belong to any resource: users, streams, apps, app content, data-connections and in fact every single facet of the Sense QMC.  Together, the created rules combine into a greater total of conditional (IF, THEN) statements to form the user’s security access.

Resources
When creating security rules, we have to define the resource filter. This answers the question: to what resource(s) should we grant rights based on the condition? By being able to set rules on all these various resources, we can be very flexible. However, when trying to create and combine rules to create roles, we found that there are a lot more resources to be used then the dropdown is suggesting, and some of those are not to be left out! Here’s a list.

QmcSection-resources
Among these resources, there are the QmcSection*-resources. What these do, is plainly allow the user to access those particular sections in the QMC. When allowed into a section, we still have to assign rights to the users to create/read/update/delete the content. Now, why we can still choose to apply these rules to Hub, QMC or both is unclear to us, for, in the case of QmcSection*-resources, they obviously only apply to the QMC. Take notice of this when building the rules. This seems a bit of a strange behaviour, and the effect in the hub of setting a rule on such a resource is not entirely clear to us.

The use of e.g. App* vs App_*
When choosing your resources, take notice of the use of ‘*’ vs. ‘_*’ as the resource filter; a slight difference, but with big impact. The first version creates a rule on every resource from App down (app_objects, app_datasegments etc.), the latter only goes for Apps. Using the first will grant access to all underlying objects, data_segments etc. Using the latter will result in visible apps in the Hub, but when opening, no content will be shown. This way, we can grant access to certain app_objects to certain users, while denying access to that data to other users – if we would want to. Very flexible indeed, but be aware of this use.

Attributes and custom properties
Resources have standard attributes. Think of a Name, an ID and maybe a Group for a user, derived from the user-connection. On top of these ‘standard’ attributes, custom properties can be created and assigned to further enrich our resources. For example, we can create the custom property “@Department”, and assign this to a stream, a user, a data-connection etc. This custom property may than be used in security rules, so that we can grant or deny rights based on a department. This is an example of course, but you may see the use in other ways.

Rules
As noted before, in Qlik Sense, the security setup is done by creating rules. These rules use conditional structures (IF, THEN) to grant or deny access. What’s important to understand, is that in Qlik Sense, a user does not have any rights, unless you
assign them. This
means we have to start from absolute scratch and that we can go every direction we want, because we can use all sorts of attributes (of users and other resources) to grant access to all types of resources. As mentioned, both inherited attributes as well as newly created custom properties may be used to create the rules.

Overlap in rules
When building security rules, we found that rules may overlap. You will notice this when you build those rules yourself, but some standard-delivered rules may overlap your rules. We found this out by setting publish rights for certain users. The user had the right to publish apps, and we thought we had restricted this users’ streams. However, a rule giving him access to all streams (streams*) was applied as well. Not so clever of course, but this might happen. Therefore:

Use the Audit function!
It’s great. It truly is.  The audit function comes in very handy when building roles using security rules. The audit-functionality gives an overview per user and his rights per resource of your choice.

When clicking on a letter corresponding to a certain right, ‘Associated rules’ becomes available. When clicking this, an overview of all rules applicable to this user/resource is shown. This way, overlap (or gaps) in rules can be spotted easily, and by clicking the rule and ‘View’, we may than go into the security rule and alter this, or even disable or delete it.

Section access
After creating the security rules, we found that also in section access, there are some differences as compared to QlikView. We do not go into this here, but find the most important things on SA in Sense here.

Hiding the Dev Hub
One last thing on giving or denying rights to users. If we want to refrain users from entering or using the Dev Hub (deny access to this section), this does not seem possible.That is, the Dev Hub is not a resource we can apply rules upon. However, when zooming in on, it, my colleague Vincent Hayward found a work around. Find his answer in this QlikCommunity-thread.

Room for additions…
So, as you might have noticed, this is just a list of things we found to be notable. If you have encountered any other items, please share them in a comment below. We might build a nice and compact knowledge base here!