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:
Column
Description
ACCESS
Can be USER or ADMIN. The ADMIN access was introduced in Qlik Sense 2.0 and gives the user full access to data.
USERID
The name of the user in the format of [User Directory]\[User ID]
GROUP
Value of the attribute group on a user
[REDUCTION]
Is the field on which the reduction is performed
OMIT
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 [
ACCESS, USERID, REDUCTION, OMIT
USER, QVNCYCLES\flp, 1, Region
USER, QVNCYCLES\kag, 2,
];
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
In the above example BISERVER-P\QLIK is a user that has been loaded from Active Direcory and has the role of Administrator. Also we place commas in order the administrator to have full access to the application, otherwise he is going to be locked. A good practice is to work in Qlik Sense Desktop and then uploading to stream in Server and adding the above script. So in case admin is locked, we can upload again the app and changing the section access script based on new requirements of our companys data policy.
Great post in general, but still I'm missing a more detailed documentation on how really Section Access works behind scenes. Cause at least to me, implementing it is always a matter of trial and error and I have the general feeling of don't fully understand how it works.
I agree with andrespa. Is it possible that QlikView and QlikSense behave differently behind the scene? I read all over the forum that Section Access "hides" the data instead of reducing it in QlikView, and that performance gets much worst when you enable section access.
I made a proof of concept in QlikSense, and it seems to be reducing the data. I have a huge dataset with 300M+ rows, and using section access, it becomes really performing when I select only the data related to a single user.
Could someone confirm that QS actually reduces the data?
Section Access is QlikView and Qlik Sense behaves in exactly the same way. Both apps hide the data from those that do not have access to it.
This is done using the associative data model, which is what makes Qlik products as good as they are.
Just as when you make a selection in a Qlik product to give a smaller set of data it will perform better, applying section access will make an app run quicker for users - as the engine only considers the data which each user has access to.
A reduce in QlikView (via Publisher) will make more efficient apps than the same app using section access - but it is also much less flexible. Separate apps are required for each data slice that is produced. This quickly becomes a bit of a management headache, at best.
Enabling section access will not slow down an application, on either platform, and if a user is seeing a subset of data it will speed up access for that user considerably.
This article has helped me understanding more clearly about Section Access in QS. But I am running into a weird problem with its implementation in QS.
Here is my script:
SECTION ACCESS;
LOAD
*
INLINE [
ACCESS, USERID, EMPLOYER_NAME, OMIT
USER, LOCALUSERS\SENSE_SYSTEM,*,
USER, LOCALUSERS\QVDEV, ABC,
USER, LOCALUSERS\QVDEV, XYZ,
USER, LOCALUSERS\QVADMIN,*,
USER, LOCALUSERS\QLIKUSER, XYZ,
USER,INTERNAL\SA_SCHEDULER,*,
];
SECTION APPLICATION;
The users QLIKUSER and QVDEV are successfully seeing the reduced data based on ABC and XYZ only but the user SENSE_SYSTEM and QVADMIN are not seeing all the data. Instead they also see the data reduced to ABC and XYZ. I have tried both USER or ADMIN in the ACCESS field for them but it just doesn't work. Can some one notice anything out of the ordinary here?
This is actually normal behaviour. The "*" will only give you all data defined in the Section Access list. In your case, you have only defined the EMPLOYER_NAME ABC and XYZ so a "*" in this case will only give you those employees. If you need to to be able to see every employee that exists, you'll have to do a distinct load of EMPLOYEE_NAME from your data and then add it these to the list.
There might be other work arounds, but this is the one I have used in the past.
