Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
.png "Former Employee"){kind=icon}
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:
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:
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.
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:
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:
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.
Summary
- 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!
HIC
Additional reading:
A primer on Section Access