<Part of http://integration.qlik.com/ and created together with raymond Neves>
Table of Contents
In OEM software integration cases, users and their authorizations are stored usually in a SQL table and the OEM website already does the authentication step. So the key thing we have to explain you in this article is how do we transfer the user and his rights to Qlik Sense? The short answer is: We usually do this by using a ticket (token based) mechanism. This ticket can be seen as a passport for the user. It contains his userId, and the groups/roles which define his authorizations.
Make sure you check the introduction and extended security videos first.
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?). For each type of authentication we can create a virtual proxy. So normally we would create a virtual proxy for each authentication mechansim your company needs:
Authorization using the security rules
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
There is no mandatory structure you have to follow in Sense. We 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 we protect the resources above with security rules, and it has the following logic:
In other words:
Example Admin 1
Example End user 1
In most OEM cases we give each customer its own stream, and therefore we create a rule like this to split the customers in the system
Lets illustrate this with the example of a city (a Sense server), it consists of
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. And that is exactly the same way with an OEM security setup in Sense.
SaaS security setup
Most times you have a SaaS solution with a lot of customers in 1 system. You want to divide this. So, we start with giving each customer its own stream, and once you have access to the stream you are allowed to view all apps. Of course we can limit the access to apps and even sheets, the script and database connections. This is possible because everything is a resource is Sense. And before a user can access a resource he needs at least one security rule that evaluates to true for the action he would like to do (read, update, publish).
Minimum requirements of the security rule
Back to our example of the street and the houses:
You always need access to a stream before you can open the app, or view the resources inside an app:
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
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:
Detailed security rules
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. We 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. For more information about Security rules see this video or the Qlik Sense help
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 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 I would recommend to give each department (HR, Finance) or customer (Customer A, Customer B) its own stream.
So we can give users access to a dashboard, and define whether he 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 won't see the edit or bookmark button in Sense.
Authorization check points
1: Security rules in the QMC: Stream, apps and other resource access control
2: Section access in the script of a QVF to provide row level security
This section contains more info about the "second step" of the picture above: Which data and fields are users allowed to see?
Section access to filter data:
We load your security table as a regular table, we put this in a special section in the script called "section Access". This behaves exactly the same as the normal script. Except that it makes a "mandatory selection" or filter if the user opens the dashboard. Note that you can load users or groups in this section access column "UserId". If you send in the ticket attribute with the name “group” it will be used to restrict on in section access. So based on the group provided in the ticket you will see only your data.
In the example on the left: if user John logs in, Qlik Sense makes a "fixed selection" which is basically an inner join between the security table and the datamodel. If John logs in, he will only see the data where department is Finance.
Security using hierarchies
Security is never a simple model, most of the time companies are organized using hierarchies. Qlik Sense allows you do authorize on this.
See this for more info on authorization using a hierarchy.
In this way you can authorize on a node, and the user will see all the children of the node. Note that this demonstrates the power of our script, the authorization on hierarchies is for example not possible with "pure visualizaton tools" which rely on 1 view to be supplied as input for the dashbard.
Example: OEM security example use case for a fictive OEM partner
Functional design of the security principles
Technical design of Qlik Sense security:
We have to configure the following layers
1: A stream per customer
2: Security Rule
In the management console of Qlik we define 1 security rule to enable "resource access control".
In the script we mark a special section as security. In the section we can limit per dashboard what a user/role can see (data filter/reduction). We do this based on the attribute: 'group' you provided in the ticket. In this way you don't need to sync user-group relationships to Sense.
Integrated security overview
The picture below outlines the complete flow from user single sign on with ticketing, to row level security via section access.
Key take aways:
To create a single sign on model you only need to
Row level security
So this is what you DON'T need to do anymore
More security documentation can be found here
Appendix A: Streams
See a demo of streams here
The content in the hub is organized in streams. A stream is a collection of apps that a group of users has specific access to. The users of the stream can have different access rights. Some users might only be able to read the content in the stream, while others might have the rights to publish their content to the stream.
Appendix B: Security flow when opening an app
Users interact with Qlik Sense using authenticated communication through one or more proxies. Information is transferred using cookies. The cookies are necessary regardless of authentication type used. When using a web browser, the web browser sends a ticket to the proxy. The proxy then returns a cookie to the browser and this cookie is included in the communication with the Qlik engine. When using a custom client, the client must set the cookie and provide it to the proxy.
Authentication is the procedure of verifying the identity and credentials of users wishing to access Qlik Sense. It can be done in various ways:
Security example: The figure below shows the flow in the Qlik Sense security system when a user logs in and opens a app.
Introduction to QlikAuth
Appendix 😧 Security approach summary
Appendix E: More information and tools about security?
Security in Sense
Using ticketing. This is an authentication module that can be used for testing access control in Qlik Sense. This is also an example of how an authentication module could look in NodeJS
This is a example implementation in Nodejs of how the Session API in the Qlik Sense Proxy can be used
Proof of concept implementation of the Load Balancing module API that implements a random load balancing algorithm
Setup header authentication
Header authentication is nice if you want to perform some tests with tools like fiddler, or if you have an architecture which uses an authenticating reverse proxy. Don't use this in other cases because a malicious user can misuse this technique.
For testing purposes it is easy to setup a virtual proxy with header authentication. Make sure you use the path for the REST calls which include this proxy. (http://srv/YOURPROXY/qrs). Don't forgot the http:// and ensure you allow http in the virtual proxy.
Example config using Postman
If you send this:
Authentication using certificates
If you have server side software you can use certificates to authenticate against Qlik Sense. In this way your software tool can talk as admin to Qlik Sense.
|Authentication using ticketing|
Export and import the security rules
Appendix F: Security rule examples
You can make the security in Sense as complex or simple as you want, I defined a couple of scenario from simple to complex.
Authorization business rule description
Only authorize on streams
Authorize on the combination of streams and apps
Authorize on the combination of streams, apps and resources inside an app (sheets, stories, script, master items)
Authorize on rows and columns
An External tool should have full access, except to delete the "Template" and "Everyone" streams and apps.
Scenario 1a: Authorization business rules Stream authorization
For our fictive company we defined the following rules
Scenario 1b: QMC Admin
Scenario 2: Authorization business rules: App authorization
Scenario 3: Authorization business rules: Sheet authorization
Scenario 4: Apply row/column level filtering
Security rule code for each scenario
Implementation of scenario 1a using the QMC - Security rules
Before we start, remember that If you want to see something, you need one or more security rules that give you access to
So in the examples below we create 3 rules (to make it manageble we splitted the rules per resource type, you can also create 1 big rule)
Modify standard rule set
Also we have to look at the standard security rule set in Qlik Sense. Here we have to disable some rules to prevent our your have too much authorizations. You can always find the rules that are active for your stream/app by going to the audit. Double click a cell, and you can see why John, has the rights to create app.objects (sheets, or basiscally all the "things" inside an app)
The rules below have to be disabled. To offer too much access to our users for now.
Access to resource
Security rule condition
Example security rule to give each user access to its stream
For use with Ticketing
user.environment.group = resource.name
For use with Microsoft Active Directory
user.group = resource.name
Example security rule to give
|(resource.resourcetype = "App" and resource.stream.HasPrivilege("read"))|
Example security rule to give each user access to
|((resource.resourcetype = "App.Object" and|
resource.published ="true" and
resource.objectType != "app_appscript" and
resource.objectType != "loadmodel") and resource.app.stream.HasPrivilege("read"))
If you want to go one step further you can also authorize on sheets:
The security rule for employee:
(resource.resourcetype = "App" and resource.stream.HasPrivilege("read")) or ((resource.resourcetype = "App.Object" and resource.published ="true" and (resource.objectType= "sheet") and (resource.name!="Finance Dashboard" and resource.name!="HR Dashboard") ) and resource.app.stream.HasPrivilege("read"))
Script: Section access
Row level security: In section access you can use the group of the ticket or AD to ensure row level security. In this way you can make sure that someone who is member of "group: Germany", can only see results in the dashboard where the data belongs to Germany.
Use the script below to authorize on groups (supplied in the ticket or via AD etc.) and on individual users
Note: normally you just load this table from your SaaS platform. For demo purposes I just do an inline load.
(resource.resourcetype = "App" and resource.stream.HasPrivilege("read")) or ((resource.resourcetype = "App.Object" and resource.published ="true" and resource.app.stream.HasPrivilege("read"))
Implementation of scenario 1b: QMC admin per customer
Access to resource
Security rule condition
Apps and Stream
An admin of a specific customer is allowed to see their own stream and apps in the QMC
Filter: QmcSection_Stream, QmcSection_App*, Stream*, App*
For use with Ticketing
For use with Microsoft Active Directory
If you then create a user in your source system, and give him the admin group. He is able to see the QMC, only for his stuff.
And he can see this:
Only his stream and only his apps which are published in his own stream
Read access but not a specific stream and its apps
View everything in the QMC except apps and streams
Scenario 30: Audit display all
Security rule summary
See Qlik help for an overview of the options in the security rules. In my multi tenant SaaS demo platform I used the rules below.
((resource.stream.name!="Templates" and resource.stream.name!="Everyone" and user.roles="QRSMeteorAdmin" and resource.IsOwned() and resource.owner = user))
Root all for apps, except the everyone and template stream apps
((user.roles="QRSMeteorAdmin" and resource.resourcetype!="App" and resource.resourcetype!="Stream"))
Everything in the QMC except the Streams and APPS
(resource.resourcetype = "App.Object" and resource.published ="true" and resource.app.HasPrivilege("read"))
see all apps if you have access to the stream
((resource.name=user.environment.group or (resource.name="Everyone") ))
end user: if you see the stream you are allowed to see all apps for your customer
and resource.published ="false" and
A user with group contributor is allowed to create sheets in exiting apps, but no app creation
user.environment.group = "Developer"
((resource.owner = user and resource.stream.Empty())
(resource.app.HasPrivilege("read") and resource.published ="false" ))
A user with group developer is allowed to create apps, sheets and load data.
QMC Menu only. Only give access to stream if the name of the stream match the AD group. Note, we disabled the default Stream Rule
user.environment.group = "Admin" and ((resource.resourcetype = "App" and resource.HasPrivilege("read")) or (resource.resourcetype = "App.Object" and resource.app.HasPrivilege("read")) )
Administrators are only allowed to maintain the apps and app.object in the QMC
Root: Hub and QMC full access