Qlikview Section Access – Some Thoughts
Security, in BI…Is that a misnomer? I usually prefer the term Privacy instead…
Nevertheless, whatever term you use for the two processes, you still have to cater to authentication and authorization to see specific data.
QlikView, going enteprise, now has quite a mature security framework to comply with various standards including SOX, HIPAA, ISO either directly or through partners like NOAD.
This means that any company which needs to certify on these standards can be rest assured that QlikView follows compliance friendly and open standards for both authentication and authorization of data as well.
However, for those coming from other data security (privacy) frameworks, like that of traditional BI or ERP environments will find some familiarities in the patterns followed but also some differences.
The security patterns and How-To’s are very well documented by QlikView, one of the good documents can be found here..
Here, I’d like to highlight on the unusual way QlikView implements one of its security models, the Section Access. Of course, there are other ways to implement security which resemble traditional approaches using the QlikView Publisher but here I’d like to focus on a quite powerful security mechanism built within an app, called Section Access which serves a number of use cases for security implementations.
Section Access is a part of the load script which basically maps a list of groups/users with authorized fields/conditions and explicitly denied fields/conditions. As a causal phenomenon, using Section Access also ends up with Data Reduction, i.e. splitting up (and reduction) of data based on defined users with their granted and denied authorizations.
Some Problems:
1 – I hear people concerned about certain drawbacks or unexpected behavior with Section Access. First of all, there is a risk that a developer can lock him/herself out of the application if not being careful. Well, yes, there should be a failsafe mechanism to warn the user of doing so beforehand but then again, the idea behind Section Access is a self-securing, self-controlling Qlikview App, independent of a centralized environment responsible for data security (privacy), in a truly disconnected, democratic analysis (btw, still retaining single version of the truth) approach. The solution, use the document versioning built in feature in Qlikview 10
and roll back to previous versions of the app if this mishap takes place. Or, simply, take a backup of an app before implementing security (privacy) to it.
2 – Some people pointed out that it is quite insecure to define the security matrix (actually the data authorization matrix) within the script. Although samples and demos are pulling in the security matrix using INLINE data loads, in reality, the idea is to have data locked in a data store with authorization only to
Qlikview script to read it, and that the script be placed within a ‘Hidden’ script tab to avoid developers to get overtly curious or just accidentally curious. The location of the actual data store can also be concealed by loading it in the Hidden script area. Of course, I am not asserting that it is totally failsafe either…
The idea behind section access for me is to add security (privacy) for disconnected analysis which is usually the norm of a few within an organization as compared to the bulk of the users who prefer the more vanilla cake ready implementations and work within corporate infrastructure to work with Qlikview applications. This can be handled by the more systematic and productive QlikView Publisher.
Bottom Line:
You have two types of security (privacy) mechanisms, the Qlikview Publisher, which is more enterprise friendly, centralized and more IT driven while the other is a unique feature which maintains the security context in disconnected analysis mode as well and also provides a self-defining, self-controlling DAR (or MAD) application.
Related Links:
http://qliktips.blogspot.com/2009/08/section-access-gotchas.html
http://www.quickqlearqool.nl/?p=822
Knowledge Works 