10 Replies Latest reply: Dec 4, 2014 4:25 AM by Peter Cammaert RSS

    Section Access applying Resctritions to Service Account User

    philipp kunz

      Hello everybody,

       

      I am struggling with an issue within Section Access.


      Currently everything is woking fine and SectionAccess restricts the Data exacty the way as it is supposed to be,

      except for the NT-User under which the QlikView Services (especially Distribution Service) is running.

      In the Section Access Part this User is mentioned with entry BLANK() on the Limitation Field in order to make a proper reduction.

      Unfortunately I cannot Quote this User again (2nd line in script) in Section Access with a Limitation on the reduction field , otherwise Section Access doesn't work anymore and Access is denied on Accesspoint for all users--> which makes sense.

      We have not set up a QVService Account on the QV-Server, so the question is:

       

      Is there a possibility to give this  ServiceAccount User (who on the one hand is an ordinary User in QlikView and on the other hand is local Admin  which has al QV-Services running under) restricted user rights?

       

      I hope I made myself clear.

      Thank you in advance.

        • Re: Section Access applying Resctritions to Service Account User
          Peter Cammaert

          Well, the blank limitation field is only there to allow Access=ADMIN users to see everything when opening a document in QV Desktop.

           

          You can try a single SA entry with Access=ADMIN and the required limitation value. Upon reloading the document on the server, all data will still be stored by the batch reload engine because data reduction is only performed upon opening the document, and the document is open before the reload kicks out all remaining data.

           

          But with this account you will never be able to inspect all data ever again.

           

          Good luck,

           

          Peter

          • Re: Section Access applying Resctritions to Service Account User
            Mahesh Agrawal

            Hi Phillip,

             

            Just provide "ADMIN" as ACCESS for that Service User  and give " *(Asterisk) " as value for Limited field in section access.

             

            This should work for you.

            • Re: Section Access applying Resctritions to Service Account User
              philipp kunz

              Hello Guys,

               

              thank you for your suggestions, but I am afraid to tell that nothing leads to the desired result.

              As soon as I mention the Service Account User a second time in the Secion Application part (regardless of BLANK or '*' in the Limitation field), the Application won't open on accesspoint again. So I have to exclude this Service account User in the Section Application Part with the "where" condition. Then every User is limited correctly except for the Service Account (can't open).

              Unbenannt.JPG.jpgUnbenannt1.JPG.jpg

              • Re: Section Access applying Resctritions to Service Account User
                Bill Britt

                Hi,

                 

                What you are trying to do you will not be able to.

                 

                If you use the blank, to reload the document it will not allow the service account to login, because in theory he has no data assign to him and so will be denied.

                 

                You can try using *, but there are issues with this also. Star needs all data that has been assigned. So, if you have North, South, East and West and you only assign North, South and East then the reload will only pull that data.

                 

                You should never use the service account to access the QVW, other than reloading the data.

                 

                Bill

                  • Re: Section Access applying Resctritions to Service Account User
                    philipp kunz

                    Hi Bill,

                     

                    thank you for your Input.

                    that was my apprehension but I was hoping there would be a workaround.

                    Many thanks for your fast Support!

                    • Re: Re: Section Access applying Resctritions to Service Account User
                      Peter Cammaert

                      Allow me to disagree.

                       

                      As long as the service account is of Access=ADMIN, there will not be a reduced reload, only a reduced AP View.

                      See documents in attachment. The QVW has section access with reduction on Region = North,South,East,West. USERIDs are all ADMINs:

                       

                      USERID A (password A) sees North South East West

                      USERID B (password B) has data reduction to North South

                      USERID C (password C) has data reduction to East West.

                       

                      If I let the QlikView Server perform reloads with Section Access user = B, then user A will still be able to view all regions in the AP, while user B (the reload account) will only have access to North and South.

                       

                      But of course I'm not making use of this asterisk trick.

                       

                      Peter

                        • Re: Re: Re: Section Access applying Resctritions to Service Account User
                          Bill Britt

                          Hi Peter,

                           

                          There are ways to get around this for sure, but best practice is to load section access before data is loaded. When you do the this "A" user becomes the "Service Account" and will load all the data and then the reduction will be applied to the other users.

                           

                           

                           

                           

                          EXAMPLE

                          Section Access;

                          LOAD * INLINE [

                          ACCESS, USERID, PASSWORD, REGION

                          ADMIN, ADMIN, ADMIN,

                          USER, USER1, U1, AFRICA

                          USER, USER2, U2, AMERICA

                          USER, USER3, U3, ASIA

                          USER, USER4, U4, EUROPE

                          USER, USER5, U4, AMERICA

                          USER, USER5, U5, *

                          ];

                          Section Application;

                          SALES:

                          LOAD * INLINE [

                          REGION, PROFIT

                          AFRICA, 1000

                          AMERICA, 2000

                          ASIA, 3000

                          EUROPE, 4000

                          OCEANIA, 5000

                          ];

                          In this example a reduction field has been added called REGION. The purpose is to

                          limit the USERS to their sales region profits.

                          USER1 will only be able to see the profits for AFRICA, USER2 the profits for AMERICA

                          and USER3 will only see the profits for the ASIA region.

                          USER4 will be able to see the profits for EUROPE and AMERICA.

                          USER5 will be able to see all regions listed in the reduction field REGION except for

                          OCEANIA.

                          Even if USER5 has “*“ for the REGION reduction field, star means “all listed values”

                          not all values for the field. Since no USER has OCEANIA listed for the REGION field,

                          USER5 will not have access to the values for OCEANIA.

                          If we want USER5 to see OCEANIA as well, we need to add an extra line in our section

                          access solution

                          USER, USER5, U5, OCEANIA

                           

                           

                           

                          Bill

                            • Re: Section Access applying Resctritions to Service Account User
                              Peter Cammaert

                              Hi Bill,

                               

                              while I do agree with you that the asterisk in Section Access is not always what you want it to be, I think this "best practice" is only applicable if the document developer has a perfect idea about what ALL-AND-EVERYTHING really means. After developing multiple security solutions in QlikView, I gradually came to believe that loading section access after everything else is a way better approach, mainly for three reasons:

                               

                              • Loading section access data from an external database makes the set of values highly unpredictable, in a sense that both the LINK values in the Section Access table, the LINK fields in the Facts/Dimension tables and any intermediate grouping tables tend to be unknown to the QlikView script.
                              • Link values may be very dynamic, in that the data source dictates what will be visible to whom, including the value of "whom"
                              • In most cases that I met, Link fields have to account for multiple reduction fields. That means that again the single asterisk won't do much good  and that the developer is on his own to expand something like *|*|* in all possible combinations of all values in three different fields. How do you do this when section access is at the front of everything else?

                               

                              Aside from all cons that can be brought up against this approach, in this thread the example with the SA at the end clearly did solve the case of not being allowed to assign a reduction value to the Reload ADMIN account.

                               

                              Thanks for your feedback.

                               

                              Peter

                                • Re: Re: Section Access applying Resctritions to Service Account User
                                  philipp kunz

                                  Hi Peter,

                                  thank you for your Post.

                                  I know how challanging it can be when it comes to more complex security mecanisms.

                                  For those who face this challenge the first time this document might be helpful.(attached).

                                  It shoud exactly cover your mention when it comes to applying data-security on more than just one field  ( f.e. 3 fields)

                                  But this 'bridge-table approach' can be applied after the section Access part.

                                  Best regards.

                                    • Re: Section Access applying Resctritions to Service Account User
                                      Peter Cammaert

                                      Hi Phiipp,

                                       

                                      your document doesn't cover the security requirements I often face. To most (enterprise) qlikview users, security has to be managed externally and in its entirety. They don't like being forced to change a QlikView script each time a new GROUPx is created.

                                      Moreover, in many cases (except in QV-based product development where they are a necessary evil) hidden scripts are seen as a feature to-be-avoided. Again security should be external to QV and shouldn't harass developers or hamper development workflows.

                                       

                                      I think there is no generic solution for managing data/document security in QlikView. It may be highly situation-dependent. I do apologize if my remarks are of no use to you or this discussion. They're just the results of my personal experiences (and frustrations).

                                       

                                      Best,

                                       

                                      Peter