Security rules example: A customer case

The following example presents a customer case where a flexible solution was developed to suit the customer's needs regarding security rules.

User directory structure

The customer had the following user directory structure that they wanted to reuse.

Project

The structure shows that the customer has multiple projects in their Qlik Sense deployment, which consists of a number of roles:

• Developers, who are allowed to develop material for this project using a folder connection.
• Admins, a kind of super users, who are allowed to administer resources in the project.
• Audiences, users who are allowed to consume defined sets of dashboards through streams connected to the respective audience.

Adding security roles and project groups

The following table reuses the original user directory structure, but adds security role and project group as two new properties.

Project (proj_X)

The new properties are used to define the different groups:

• Security role: defines what actions a user is allowed to perform (create apps, add sheets, export data, and so on).
• Project group: decides what projects and which project resources that a user is allowed to access.

Implementing the new properties

Project groups are implemented through the use of custom properties, which give access to projects and resources. Security roles are implemented in the user directory.

There are a number of benefits to this approach:

• The number of rules needed to describe the security policy is reduced.
• Rules change slowly. The system is configured through attributes, and it is only when security needs to be changed that rule changes are required.
• User management and provisioning of permissions are maintained in the user directory.

What rules need to be created?

One rule is needed for resource access.

This rule will grant a user access to a resource, if the resource custom property GroupAccess contains the group name of the user. For this to work, a custom property called GroupAccess is needed, containing all user groups.

This rule can be connected to streams and data connections. The rule makes it is possible to grant users in the groups access to streams using a custom property.

In this example, the proj1_aud1 group has been added in their user directory access to the Proj1_Aud1 stream. If additional groups need access, they can be added to the custom property.

The next rule to be created defines who should be allowed to administer the streams.

Description of the rule: if you are part of the admin group for a stream, you can manage resources related to the apps published in that stream.

For this to work we need to create the custom property AdminGroup containing the names of the groups that contain admins for the projects.

In this example, users in the group proj1_admin have administrative access to resources related to apps in this stream.

What security roles need to be created?

Three different security roles have been defined:

• role_admin: users who need to be able perform admin tasks
• role_dev: users who need to be able to perform development work in projects
• role_ext: users who need to be able to extend apps

The admin role requires two rules. This following rule gives users in the role_admin group access to sections in the QMC.

The following rule gives users in the role_admin group the possibility to create, among other things, apps, reload tasks, and data connections.

The role_ext rule is created by tweaking a default rule. Only users in the group role_ext are allowed to extend apps with new sheets. To add flexibility, a new custom property (Extendable) is added to apps. An app marked Extendable allows all users to add sheets to that app.

Finally, for the developers, another rule is tweaked, so that only developers in the role_dev group are allowed to create apps.

Summary

With this setup you can manage Qlik Sense through the groups in your user directory and when you add content to Qlik Sense, you only use the attributes to define what the groups should have access to.