6 Replies Latest reply: Nov 28, 2016 3:50 AM by Miguel Angel Baeyens de Arce RSS

    row level security, how to?

      How to implement a "row level security"?

      I'm testing Qlik Sense for the first time and the first critical point is the security.

      so how to implement some sort of row level security to display only the authorized data to the users.

      Like sharing a store dashboard where each user can only see his store data.

      I'm using the direct discovery feature, but I'm not able to find how to send the current user name in my queries.

      in my database I have a table listing which store a user can access.

       

      so how to do this?

      the help site has very limited description about the data security.

       

      thanks.

        • Re: row level security, how to?
          Miguel Angel Baeyens de Arce

          Hi Jerome,

          Qlik Sense can use Section Access too, besides security rules, to make sure that you have row level security in place.

          There is more info here: https://help.qlik.com/sense/en-us/online/#../Subsystems/Hub/Content/Scripting/Security/ManagingSecurityWithSectionAccess…

          Miguel

          • Re: row level security, how to?
            Jonathan Poole

            Jerome

             

            There are a number of things to keep in mind when setting up Section Access for row level security.  The following provides additional tips not found in help.qlik.com.  Its meant to go over row level security in more detail. it doesn't talk about column level security . hope it helps.

             

             

            1. The section statements should go in the load editor before the data load segments. In the sample below, I load the Section Access table before the rest of the data model.


            2. The Section Access table requires an ACCESS field and a USERID or GROUP field.  Under USERID, you will use the userid that the Qlik Sense hub uses to track all users . For default security, its likely to be in a DOMAIN\USERID format.  I suggest entering the USERID or GROUP reference in all caps as you see below


            Capture.PNG


            3. To do row level security, add 1 more other fields to the Section access table. The field names should be capitalized as should the data values in those field(s). You don't need to alter your source data, just alias the field name in the section access table to provide a capitalized field name and use the upper() function to put the values in all caps as well


            ex:

            section access;

            LOAD

                  'USER' as ACCESS,

                  USERID,

                  upper(Department) as DEPARTMENT,

                 upper([Cost center id]) as [COST CENTER ID]

            FROM ...;


            4.  In the rest of your data model you must also have the same all caps field names and data values (see below).  The way it works is that when a userid logs in, it will  act as if the whole app was filtered based on the records with the field values (or combination of field values if you have multiple fields)  referenced in the section access table for that userID. The associative indexing is intact for this action so that all linked tables will likely be filtered based on those same field values. 

             

            LOAD

                  upper(Department) as DEPARTMENT,

                  upper([Cost center id]) as [COST CENTER ID],

            Department,

            [Cost center id],

            Sales

            FROM ...


            5. You CAN put an asterix '*' for a field value entry in the section access table if you want that user to see all values.


            6.  Section Access only works on Qlik Sense Server.  An app with a valid section access table in the load editor must be on the server AND reloaded on the server for the security to take effect. To test different users access, you must publish the app to a stream so that you can test logging in as different users to see the effect. Without publishing the app is stuck in the 'my work' of one user and not accessible by other users.


            7. ALWAYS create a backup or duplicate of the app prior to adding any section access statements to the load editor.

              • Re: row level security, how to?

                thanks for the information appear to solve most of my challenge

                 

                what's the impact if I want to give access to aggregated information for the district level (sum of all stores in the district) of my stores, but only the authorized store(s) when only the stores are requested?

                does this security model will works too?

                  • Re: row level security, how to?
                    Jonathan Poole

                    I think you could do that but i'm not sure it could be done with Section Access, but perhaps just with modeling techniques and UI expressions.  The only issue is that by deviating from section access, the security is no longer pervasive and you need to give thought to whether the users would ever interact with the data model (self service) or just pre-created dashboard widgets and pre-created expressions. My gut tells me the latter would be necessary.

                     

                    Basically you add a table to the data model that ties users to stores.

                     

                    Then in the UI expressions tie that table into the expression in some fashion. 

                     

                    Store level calc:  sum (  if( osuser()=User,Sales) )      ...where user is the field that stores the userID in the table

                    District level calc:   sum (Sales)

                  • Re: row level security, how to?
                    Louis Lam

                    5. You CAN put an asterix '*' for a field value entry in the section access table if you want that user to see all values.



                    Is it possible to set the user to see nothing in that column but not filter out other value?