Qlik Design Blog

9 Posts authored by: Fredrik Lautrup

When we developed the security rules for Qlik Sense, I didn’t anticipate the wide adoption of these for defining new administrative roles in the QMC. But now that Qlik Sense has been in the market for a while we can see that the need for distributing administrative tasks to users is something that is widely needed and used.


It is not strange that this is a requested feature as when we introduce self-service concept for the client why would you not want to have the same experience for administration.


So in this post I would like to share two tips and tricks that will help you create these distributed administration roles.


The first thing I’m going to cover is the general structure of defining an administration role.

Admin role.jpg


There are three parts to an administrative role: Defining the role using rules, assigning it to a user and defining the scope they should be able to administrate.


To define who should be admin we can use things like custom properties, roles and user directory attributes. Each having its own pros and cons.


To define the role, you may need up to five rules. One each to define what you are allowed to read, create, edit and delete and then you need a fifth rule to define the sections in the QMC that the user is allowed to see. Sometimes you can collapse multiple rules into one, such as when the user is allowed to read and delete the same resources, then you only need one rule. The only rule that you should keep separate is the create rule, this will avoid some simple mistakes.


For the custom roles you often want to limit their scope by using some type of filter on resources. Typical things we see customers filter on is custom properties, streams, ownership and name. For example, to create a document admin you could filter on name of app or if you want to create a stream admin you will filter resources base on which stream they refer to.


You can find example roles in our documentation


The second thing I wanted to cover is that there are some common things that an administrator like to be able to do that require multiple permissions to resources. One example is duplicate. The table below should help you understand for what tasks multiple permissions are needed.


Adminstrative taskAppStreamApp.ObjectData ConnectionUserSyncTaskReloadTaskUserDirectory
ImportCreate and UpdateCreate (if new data connection in the imported app)
Start UserSyncTaskReadUpdate
Start Reload TaskUpdateRead
Duplicate app in QMCRead and CreateRead (Otherwise App will be duplicated but only app objects that the user has read access on will be included on duplicated app)
Publish appRead and PublishRead and PublishRead (Otherwise App will be published but only app objects that the user has read access on will be published)
Publish and replaceRead, Update and PublishRead and PublishRead and Update


I hope that you found these tips on creating custom administrative roles helpful. If you have questions on this blog post or have ideas of what you want to read about in the future, please don’t hesitate to add comments to post

For any BI tool to work it needs to understand who is using the tool. If we know who is using the tool (authentication) we also need to understand things about them such as where they work, e-mail address etc. If we know who the user is and what describes him/here we can do things like giving them access to the right information and tailor their experience. We therefore have methods in both QlikView and Qlik Sense to access information describing the users in user directories. Even though we have this capability in both QlikView and Qlik Sense, their approach to doing it is very different.


The most common user directory used by our customers is LDAP. LDAP is a distributed database that is suitable for maintaining user information.  It exists in both open solutions developed by the open source community (such as OpenLDAP) and in closed solutions (such as Microsoft Active Directory).


So what are the differences between QlikView and Qlik Sense?


QlikView is based on the concept with a directory service connector that fetch user information as it is needed. It doesn't replicate any data stored in the LDAP database, but instead asks a question every time it needs access to user information including groups.


Qlik Sense uses a sync approach, which means that it replicates the user information including groups from LDAP into a database and then keeps this in sync. This can be done in different ways (sync all users, sync with a filter, sync only users that access Qlik Sense) depending on your needs and size of directory.


There are two major usages of the user information, each with different needs: for management and for access control/authorization.


For management it is good if the information is current but not absolutely critical, so here the Qlik Sense scheduler is used to update the data.


For security however, it is critical that information is current. Therefore individual user records are updated as the user connects to the Qlik Sense environment.


So, are there any similarities in how you configure Qlik Sense and QlikView?



In the picture below I describe the relations between QlikView LDAP configuration and Qlik Sense LDAP Configuration.

QlikView to Qlik Sense Mapping.png


I hope that you found these tips on how we access user information helpful. If you have questions on this blog post or have ideas of what you want to read about in the future, please don’t hesitate to add comments to post.

Almost every person I meet to talk about Qlik products and security bring up the concept of section access for discussion. I think section access is one of those things that you either love or hate, but as a company using Qlik products you can’t live without it. The great benefit of section access, in my view, is that it’s driven by the data model which makes it really powerful.


It would be great to get your comments on what you think are the strengths of section access.


As section access is a critical part of how we protect data, we carried over its capabilities from QlikView to Qlik Sense and adapted it to Qlik Sense architecture.


So what has changed?

In Qlik Sense the section access is different in that the names of the columns available have changed:




Can be USER or ADMIN. The ADMIN access was introduced in Qlik Sense 2.0 and gives the user full access to data.


The name of the user in the format of [User Directory]\[User ID]


Value of the attribute group on a user


Is the field on which the reduction is performed


Fields that should not be available to the GROUP or USERID

In Qlik Sense, a script for section access could look like the following:


section access;

load * inline [


USER, QVNCYCLES\flp, 1, Region




The example above would give the user QVNCYCLES\flp access to rows with a one in the field called REDUCTION without getting access to data in the Region field, and QVNCYCLES\kag would see the data with a two in the REDUCTION field.

In Qlik Sense section access is applied using strict exclusion, which means that if you are not explicitly granted access you will not be allowed to see any data.

My favourite improvement in section access for Qlik Sense is that it will be harder to lock yourself out of an app. In Qlik Sense you have the option to open an app without data. This means that if you have permissions to change the script you can open the app without data even if you don’t have access to any. This will allow you to change the section access part of the script instead of being locked out.

We have also introduced the capabilities to use attributes sent in at the time of the user authentication to be used with section access. This means that we now can base what data you get access to using the group attribute that can be inserted using SAML or tickets. 


I hope that you found these tips on Section Access for Qlik Sense helpful. If you have questions on this blog post or have ideas of what you want to read about in the future, please don’t hesitate to add comments to post

Qlik Sense uses Attribute Based Access Control (ABAC) as a basis for its security. In this post I will explain why we decided to implement this, and give you an understanding of the future of access control.


Is it only Qlik that thinks that ABAC is the future of access control? No


When Gartner predicts the future of access control, they say

“By 2020, the majority of enterprises will use attribute-based access control (ABAC) as the dominant mechanism to protect critical assets, up from less than five percent today.” (http://www.issa.org/resource/resmgr/JournalPDFs/feature0614.pdf)

And the National Institute of Standard and Technology (NIST) has released a special publication to raise awareness and help with making effective implementations of ABAC (NIST SP 800-162 http://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.sp.800-162.pdf)


If this is the future, what is then ABAC? I have taken the liberty of changing the NIST definition of ABAC to be consistent with the syntax (marked in bold green) that is used in Qlik Sense.


An access control method where user requests to perform actions on resources are granted or denied based on assigned attributes of the user, assigned attributes of the resource, environment conditions, and a set of security rules that are specified in terms of those attributes and conditions.


This sounds pretty generic. So why is ABAC seen as an important step into the future of access control?


The first major benefit is that with ABAC you can implement other well-known access control methods such as mandatory access control (MAC), identity based access control (IBAC) and role-based access control (RBAC). This makes it very flexible and therefore suitable to solve most company’s security needs.


But are there other benefits? Yes.


You can develop an access control policy independent of users

We have a language that can be used to describe security policies that Qlik Sense understands and be used to enforce the security controls needed.


Accommodating the unanticipated/external user

We can describe the security controls using attributes of resources and users. With this approach new users accessing the system will be in compliance with defined policies, and access will be granted based on the assigned attributes.  No additional configuration is needed in Qlik Sense.


Avoid role/group explosion

Using logic conditions in our rules, we no longer need to create new roles/groups to grant new subsets of user access.


Easier management

The administrators of the system don't need to understand or change the security policy; they only have to ensure that resources and users are correctly described by their attributes for them to be in compliance with the security policy.


Cater for taking more things into consideration for security decisions such as dynamic attributes (environment)

With ABAC we can start using the environment (the context in which the security decision is made, e.g. if the connection to the system is encrypted or not) to describe our security policy.


Hopefully this has provided you insights to why ABAC is the future of access control and the benefits this will bring to your Qlik Sense deployments. If you have questions on this blog post or have ideas of what you want to read in the future please don’t hesitate to comment this post.

For those of you who are interested in how tickets can be used in Qlik Sense to integrate authentication with identity providers, you should continue reading.


Tickets as a means to give users access to things was used long before the invention of computers. When you go to the cinema, you first need to buy a ticket from a cashier or from the Internet – a ticket that is valid for one movie at a certain time. The ticket is later validated by the person letting you into the correct theatre for the movie for which the ticket is valid.


One benefit of a ticket system is that it is independent of how you get the ticket. The ticket is valid for access to the movie, no matter what.


So how can we use the same concept to gain the same flexibility when we authenticate users in Qlik Sense? We use tickets, but this time the tickets are digital.


In QlikView 11.0 we introduced a concept that called Web Tickets. In Qlik Sense we have developed this idea further and this is now the normal way to make the authentication.


So how does this work in Qlik Sense?

  1. You connect to Qlik Sense Proxy and try to gain access, but as you don’t have a session yet the proxy will ask you to go to an authentication module.
  2. You go to the authentication module that can validate that you are who you say you are.
  3. You get validated by the authentication module based on something you are, something you have, or something you know.
  4. If successfully validated, the authentication module will request a ticket from the proxy. As the proxy trust the authentication module it will grant a ticket. The ticket is special in that it is only valid for the person you say you are for a short period of time.
  5. You can now return to the proxy with the ticket. The proxy will validate the ticket and grant you access to Qlik Sense.



So how do this look in real life if we wanted to integrate with Salesforce?

  1. You enter https://[Server name]/hub in your browser
  2. You get redirected to an authentication module  by the proxy with an identifier of where the module can request a ticket, the proxyRestUri,  and a token that can be used to get the proxy to tell you where it should send you back, the targetId
  3. You get validated by the authentication module that uses Salesforce to authenticate the user based on something you are, something you have or something you know.
  4. The authentication module sends a request (HTTP POST) for a ticket to the proxyRestUri/ticket in JSON format like this.
    And gets a response like this
    "UserDirectory":" SalesForce",
  5. You redirect the user back to the targetUri with the ticket (https://testsrv.test.com/hub/?QlikTicket=iokrVXS-IndQgEON) and the user will be granted access to Qlik Sense


But for this to be secure, there are two requirements:

  1. The call to the proxy is only allowed if the authentication module is trusted by the proxy. This is achieved by the use of certificates (which can be exported from the QMC).
  2. The request for a ticket to the proxy must contain a Cross Site Request key in the header (X-Qlik-Xrfkey) and the same key must exist in the URL (Xrfkey).


If you would like to get your hands dirty, you will find examples on ticketing on Qlik Branch and more documentation on the Qlik Sense help site

When we designed Qlik Sense one important aspects was to start using standard security components where possible to solve different aspects of security. Protecting communication is a good example of this, as we used standard components to protect against adding rogue servers and eavesdropping.


If you interested in understanding how we achieved this in Qlik Sense then continue reading…


When Qlik Sense needs to exchange information between different services, a couple of things need to be in place. The services need to trust each other and they need a way to talk without other listening in to the conversation.


In Qlik Sense all communication between services and clients use web protocols. With these we get the option of using a widely deployed standard for building trust and protecting the communication from eavesdropping. The way of achieving secure communication is tightly knit together by two components:

• TLS (Transport Layer Security), the protocol for how encryption and exchange of information/keys works

• Certificates for authentication of the servers that need to communicate


What TLS supplies is a way to build protected tunnels between two identified servers using encryption. The identification of the servers that communicate is done using certificates. Each tunnel needs two certificates, one to prove to the one starting the communication that they talk to the correct recipient and one to prove to the recipient that the one wanting to communicate is allowed to do so, i.e. mutual authentication.


So how do we know if the certificates are valid for communication between the servers? All certificates that belong to a trust zone are signed by the same signature (root certificate) and only if this signature exists will they be accepted as proof that you belong to the trust zone.


When these protected tunnels are in place and we have the right certificates in place we are able to build a trust zone for all Qlik Sense services to work within. Within the Qlik Sense trust zone only the services belonging to that specific Qlik Sense installation can communicate.



Outside this trust zone we have the clients (Qlik Management Console and the Client). These components are running on less trusted end user devices; therefore we do not allow them to be part of the Qlik Sense trust zone. The only component that can bridge the two zones is the proxy (but there may exist more than one bridge in an installation). The criteria for being allowed to cross the bridge and communicate in a controlled way with the servers in the trust zone is that you can authenticate (show who you are) to the system so it can determine if you are allowed to cross the bridge.


Even though the clients are not part of the Qlik Sense trust zone, protected tunnels (TLS) play a vital role in securing the communication between the client and the proxy, as sensitive information is sent across this connection. But as this is a different trust zone a certificate with a different signature should be used for client communication.

This is not easy to answer, so let me walk you through the flow in QlikView and talk about the life of the different sessions in QlikView.


Let’s start at the browser. The most common way of maintaining a session in the web layer is session cookies. Session cookies is a small set of information that the browser will send with every request in a session. Session cookies is also what QlikView uses to maintain the web layer sessions. So once authenticated, QlikView knows who you are and will assign a random set of characters, stored in a session cookie in the browser, to identify your future requests to QlikView.


The session cookie will identify your requests until you either log out or your session times out from inactivity.


The web session is the first session you will encounter using QlikView. The second session is the QlikView server session.




So what is a QlikView server session? Think of the QlikView server session as the place where QlikView keeps track of what you are doing in a document. The session is identified by a user’s access to one document. As you click in the document, your state will be recorded in the session. Your session is maintained in memory while you are active in the document and a bit longer. When a QlikView server session times out, the state is written to disc. If you come back to the same document later you can continue exploring at the same place you left off.


So when are the different sessions used?


If you use the AJAX client, both sessions are used. If you lose your web session you will have to re-authenticate to get a new session and if the QlikView server session times out you will have to reconnect.




If you use the thick client or the plugin, these talk directly to the QlikView server and therefore only use QlikView Server sessions.


The timeouts can be configured: the timeout configuration you do in the QMC is related to the QlikView Session; whereas the timeout values for the web session only are configurable in the local configuration file for the web server.


So now you know how sessions are used in QlikView. Even though this is not directly related to security, it will help you understand concepts like load balancing, web tickets and authentication in QlikView.


I hope you found this information useful, if you have any other subjects related to security that you like me to write about please leave a comment.

When you use a platform that consists of several services such as QlikView, you need to build trust into the platform to make it secure.  The trust will protect the platform from external threats pretending to be part of the QlikView installation to get access to information.


Every time you go from one trust zone to another you need to cross a trust boundary and that means that you need to authenticate. Examples of when you cross trust boundaries in QlikView include going from your computer trust zone to the application using the browser, using the browser to access the administrative interface, loading data from a data source into QlikView, and each time you need to authenticate.


In QlikView, there are two ways to create the internal trust zone between the QlikView Services:

  1. Windows Integrated Security: the services will authenticate to each other through the use of Windows built in Security.
  2. Certificate Security: each service needs to have a valid certificate from the QlikView installation to be allowed to communicate.


Both of these create trust between the services and hinder unauthorized computers from being able to interact with the QlikView Services, but there are situations where one is better than the other.


You need to protect the communication between the QlikView services from eavesdropping
In this case you should choose certificate trust because that also enables encryption of all traffic between services using SSL/TLS.


You only use Windows infrastructure
Choose Windows Integrated Security as this will be where you have knowledge and it is easiest for you to setup.


All QlikView services do not have access to the Active Directory or you dont have an Active Directory
Use certificates these will function without a Windows Active Directory.


It is also important to understand that you cannot mix how you create trust in QlikView; either you use Windows Integrated Security or you use Certificates.


When you have chosen the most appropriate way of creating trust, look through the technical requirements found in the Server reference manual before installing to make sure it fits your needs and environment.


To summarize, QlikView has two ways to create trust between services.  Both have their benefits; however there are use cases when one is preferred over the other. Which have you used and what benefits have you seen?  I would be interested in your comments and questions!

Authentication and Authorization are two important concepts in securing any application.  Let’s start with some simple definitions.  Authentication makes sure that the person accessing the system is the person he says he is.  Authorization only lets you access information and complete actions that you are allowed to, based on your identity.


In QlikView, these are two distinct activities performed independent of each other.  This often creates some confusion and configuration errors, so let me explain how it works.  When a user gets access to QlikView it is always done in these four steps:


One of the most common misunderstandings around this is what services are part of what step in the process.


The first two steps covering authentication are handled by the web layer (i.e. QVWS or IIS).  The third step is achieved by the web layer transferring the identity to the QlikView Server using the QVP protocol.  The fourth step is authorization and is handled by the QlikView Server using groups resolved by the Directory Service Connector.


There are some big benefits to this approach:

  1. QlikView does not have to store passwords; these are stored by an identity provider such as LDAP or AD.
  2. Normal procedures for user management can be applied, which enables that adherence to security policies are maintained.
  3. It is possible to customize authentication without affecting authorization, which gives us the option to use external identify providers such as Google and Salesforce.
  4. All Authorization is done in the backend, making it easier to protect.


The role of the Directory Service Connector in the flow is somewhat blurred by the fact that almost all QlikView components use it. The web layer, QlikView Server, QlikView Management Service, and the QlikView Publisher all use the Directory Service Connector for different things.


Most QlikView components use the Directory Service Connector for authorization or to get information about users except if custom users are used.  If you use custom users, these  get authenticated towards the Directory Service Connector, which in this special case stores identity and passwords for the users.



Remember, as a rule of thumb: the front end components handle authentication and the backend components handle authorization.  I hope this help gives you a clearer picture of how QlikView handles authentication and authorization and which components are used in which part of the flow.


Have further questions you’d like me to answer?  Leave me a comment!

Filter Blog

By date:
By tag: