Basics for complex authorization

[hic]

Authorization is about determining which data a user is allowed to see. QlikView has several different ways by which you can reduce the data so that the user only gets to see the data he is allowed to see.

[hic]

In the simplest case, the authorization table defining who-gets-to-see-what is just a two column table linking user names to e.g. regions. But sometimes you need a more complicated logic. It could be that you have users that are allowed to see all products but just within one region, and at the same time all regions but just for one product. In other words, you want to make the reduction in several fields with the possibility of OR-logic.

QlikView can do this and here’s how you do it:

1. Create an authorization table by loading the authorization data into QlikView after concatenating the reducing fields into one single generic authorization key:
   
        Load USER, REGION &'|'& PRODUCT as %AuthID From AuthTable ;
   
   
   
   
2. Create an authorization key in the table with the most detailed transactions:
   
        Load *, Region &'|'& Product as AuthID From OrderDetails ;
   
   If you don’t have all the necessary keys in the table, you can fetch fields from other tables using Applymap. See more about Applymap here:
   
   
3. Create an authorization bridge table linking the two above tables. Since the %AuthID field can contain generic symbols such as '<ANY>', several load statements are needed to create the bridge table:
   
        Load Region &'|'& Product as AuthID, Region &'|'& Product as %AuthID  From OrderDetails ;
        Load Region &'|'& Product as AuthID, Region &'|'&'<ANY>' as %AuthID  From OrderDetails ;
        Load Region &'|'& Product as AuthID, '<ANY>'&'|'& Product as %AuthID  From OrderDetails ;
        Load Region &'|'& Product as AuthID, '<ANY>'&'|'&'<ANY>' as %AuthID  From OrderDetails ;
   
   
   
   
4. Reduce the file on the USER field using either Section Access or QlikView Publisher.

Using the above method you can create quite complex security models. For instance, you can use generic symbols also for product groups. Read more about generic keys in this Technical Brief.

Good luck!

HIC

Further reading related to this topic:

A Primer on Section Access

Data Reduction Using Multiple Fields

Authorization using a Hierarchy

[YoussefBelloum]

Thank you. very useful, very clear !

[vchuprina]

Henric,

Thanks for solution its very useful. What you can recommend to do in case if we should reduce data based on ten fields.

[mpbtejada]

Can I get some help with this implementation of NTNAME as well.

Encountered the same case where I can open in Desktop but could not in Accesspoint.

Already tried adding STAR is * and checked that there are no blanks in the section access column but still could not make it to work in Accesspoint.

[jgarciaf106]

Hi hic,

Do you have any real example of this type security?

I would like also to know how can this be applied with a third reduction field?

Thanks in advance

[rammuthiah]

Hi,

Can you explain on how to implement Data Reduction using 4 fields in Qlik Sense?

Region,

pbu,

division and

empcode

[nesawant]

Hi Luca,

I am facing same issue. My complex authorization with bridge table works on desktop but when I run it from server it says you do not have access.

How do I resolve this using single section access file?

Best Regards,

Neha

[Anonymous]

Hi Henric,

My question is how can i use this complex authorization with more than 2 fields in section access. And with one field having condition of "All except one" like you explained in this thread Section access - exclude just one value!

So, i need combination of both of these solutions: Section access on 4 fields and 1 field with exclude just one value.

Appreciate your help here. Thanks

[krishgk_ispot]

@Henric Cronström@cesaraccardi Did you figure out the solution for excluding the data using <NOT A>  or <NONE> (as shown below) ?

section access;

load * inline [

ACCESS, USERID, CUSTOMERID_ORDER,CUSTOMERID_SALES, OMIT

USER, USER1, 1, 2,

USER, USER2, 2,<NONE>,

USER, USER3,<NONE>,3

];

Also i would like implement the security on a CustomerID field from dimension  table but restrict different CustomerID's from Order and Sales Tables.

Note: CUSTOMERID_ORDER and CUSTOMERID_SALES are alias of CustomerID field from Customer table.

Is it possible to restrict the data this way using single dimension filed on multiple fact tables differently?

[ansarikashif2017]

This is a brilliant article. Thanks @hic 

I have  question.

In case your dashboard has 2 entry point for authorization. Data model has two reference data set.Lets say Ref1 and Ref2.

The user can be given access to the dashboard based on field1, field2 and field3 of Ref1 and field1, field2 and field3 of Ref2.

We can combine fields of ref1 as single authorization key but what do we do with the Ref2 fields?

Regards,

Kashif

[axnvazquez]

[DELETE PLEASE]