Qlik Community

Ask a Question

Qlik Design Blog

All about product and Qlik solutions: scripting, data modeling, visual design, extensions, best practices, etc.

Qlik Highlights 2020 Giveaway! Watch, reply and have a chance to win a $200 Amazon Gift Card! Watch Video

Implementing Section Access in Qlik Sense SaaS can be challenging. There are several hurdles: The user name could be different in the cloud than in an on-premise installation, and the logic in Section Access is different between Qlik Sense and QlikView. This blog post will help you set up a secure solution.

Security in a Qlik app is often achieved using a feature called “Section Access”. It is an extremely flexible and useful feature that permits row-level security inside an app. It also allows data-driven security definitions instead of manually defined static rules. See more on A Primer on Section Access.

The basic idea is to load an authorization table that defines what different users are allowed to see:

Section Access 1.png

When the app is opened, the Qlik engine makes an invisible selection corresponding to the proper user scope (COUNTRY) and removes all excluded data, also in other tables. This way, each user will only see what he or she is authorized to see.


User name

In QlikView and Qlik Sense on Windows, the user name needs to be in the NetBIOS format:

NetBIOS UserName 2.png

But this user name cannot always be found among the claims of the identity provider used in the cloud. To see the claims of your identity provider, you need to log on to Qlik Sense SaaS and append “/api/v1/diagnose-claims” to the URL:



You will then get something that, when formatted, is similar to the following:


Here you can see the attributes sent by your identity provider to Qlik Sense SaaS . In this example, there is no attribute among the claims that corresponds to the NetBIOS user name. 


Solution 1

When you set up your Qlik Sense SaaS tenant, you should make sure that the NetBIOS user name (also called sAMAccountName) is mapped to the “sub” claim. This will be compared to NTNAME and USERID in Section Access.



If you do this, your on-premise Section Access will work in Qlik Sense SaaS . No other changes are needed. You can use an authorization table like the one below, both on premise and in the cloud, since the field NTNAME now works in all Qlik platforms.

Section Access 2.png


Solution 2

Without the NetBIOS user name, you need to authenticate the user in a different way, e.g. through the e-mail address. But this means that you need to modify your authorization table slightly. The new table could look like this:

Section Access 3.png


Note that each user now has two records: One for on-premise access, one for cloud access. The wildcards ensure that only the relevant authenticating fields are used.

The simplest way to create the duplicate records is to add a second Load statement in the script:

Two Load statements.png


The SERIAL field is used for an environment test. Without it, the records pertaining to cloud would give access to all users in an on-premise QlikView environment: Existing QlikView installations ignore the field USER.EMAIL. But with the SERIAL field, QlikView will deny access for all records where SERIAL doesn’t have a wildcard.


Solution 3

Use groups in NTNAME or GROUP to identify users. These fields will be compared to the "groups" claim.




  • NTNAME can be used in all environments. On-premise it is checked against the name of the authenticated user. In Qlik Sense SaaS it is checked against the “sub” claim and the "groups" claim. 
  • USERID can be used in Qlik Sense SaaS . It is checked against the “sub” claim. 
  • GROUP can be used in Qlik Sense SaaS . It is checked against the "groups" claim. 
  • USER.EMAIL can be used in Qlik Sense SaaS where it is checked against the “email” claim. It does not yet work in other platforms.
  • SERIAL can be used in Qlik Sense SaaS as an environment test. It passes the test if it contains the string ‘QLIKCLOUD’. The corresponding check does not yet work in QlikView.
  • The prefix ‘USER.’ is reserved for new Section Access fields.


Finally - we will continue our work to improve Section Access so that customers can create one single authorization table that works across all platforms.

Good luck with your cloud deployment!


Additional reading:
A primer on Section Access


Thanks for your post @Henric_Cronström , it will be of great help!
Could you confirm that the new USER.<something> fields are not yet described in the help? If they are, could you link the page?

Many thanks,


The help is (probably) not yet updated, but it will be shortly. 

So far, only USER.EMAIL has been implemented, but we are looking at other fields also.



Like many of your posts I'm sure this will come in handy - thanks.

You don't explicitly refer to it here, but we still need to capitalise all the field names and values to get SA working (yes, I forget that occasionally).  Does the "work to improve Section Access" include removing this need by making it either case sensitive (allowing both upper & lower case) or case insensitive (not necessarily a good move...) ?




Great article @Henric_Cronström , which I knew about /api/v1/diagnose-claims when figuring this out ourselves! 

Re "work to improve Section Access", I haev similar query to @jsebrightqi . I am hoping there is something in the pipeline to improve/streamline Section Access and make it more configurable via a GUI? Not sure how that would work, thinking i through, as its so configurable as is!

Specialist III
Specialist III

I have used the IDP Subject

Section Access;
LOAD * inline [


It seems to work well.