Skip to main content
Announcements
Live today at 11 AM ET. Get your questions about Qlik Connect answered, or just listen in. SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

QlikView Security options

Hi all,

I am just investigating how qlikview handles it's security for server. Is there a way to handle security at a row based level? Eg: Victorian sales rep's can only see Victorian sales data? Or is this just a case of forcing a filter on each Qlikview file?

And is there column level security? Eg: Only managers can see the wholesale price of stock?

I am aware that security can be applied at the data level, but I am guessing administering this process would not be user for a basic system admin... it would probably involve a developer?

Also, could I get some information on how to apply this type of security? Is Publisher required and how does it extend these features, if at all?

If you could also point me in the right direction to start investigation this (manual, threads, etc), it would be much appreciated.

Cheers,

Ryan

1 Solution

Accepted Solutions
johnw
Champion III
Champion III

I suppose "distribution" is really the wrong word. I use it because that's what Publisher calls it. While you CAN email it to the users, or push the file to their PC if it's on a network, and that sort of thing, that's certainly not what we do here, and is probably not the typical approach. The "distributed" files still typically reside on the server.

Let's say you write an application for your customers to use, and maybe you have a hunded customers. You write the application once, loading ALL customer information into it. Then you tell Publisher to create a copy for each customer with ONLY their data on it. You now have a master file that NO customer can access, and a hundred different customer files. All of these files would typically still reside on your server, and each customer would only have permission to see "their" file. They wouldn't be able to see anyone else's file.

Without Publisher, using section access, I believe there would only be one file, rather than one file per customer. The QlikView application itself would control access, and only allow a given customer to see their own information, even though technically all customer data is in the application at the same time.

View solution in original post

5 Replies
johnw
Champion III
Champion III

Yes, there are at least a couple of different approaches for handling row-based security. The two I know of are section access, which is coded into the application itself, or data reduction, in which data is actually REMOVED from the application before being distributed to the users. Publisher is not required for section access, but I believe is "required" for data reduction, as the data is reduced as part of the process of publishing the document. Mind you, there are ways to more manually reduce data without using Publisher. Publisher just makes it easy.

As far as column-based security, yes, but perhaps trickier, such as linking the display of columns to the existence of particular rows of data. Someone may know of a better way.

I'm not sure exactly what you're asking about a system admin vs. a developer. In our shop, user groups are managed by a security manager. Then we have three QlikView administrators that manage the distribution and reduction of data for documents going to people in those groups. So in our shop, developers are not involved in security, except in the sense that our QlikView administrators also happen to be developers. The roles are separate, though, and handled in different products (QlikView vs. Publisher).

Security isn't really my area of expertise, and our shop's simple security needs have been easily handled with Publisher, so I'm not sure where to point you for additional information. Hopefully someone with more experience with security can help out.

Not applicable
Author

Hi John,

Thanks for you prompt reply.

When you mention the data: REMOVED from the application before being distributed to the users could you please explain this? We will be operating in an enterprise server license, but are you suggesting actually send files around to users? Or is this meaning that you will publish the files to the qlikview server and the user will only see their specific version which was created by Publisher? I am not sure conceptually what you mean here?

Cheers,

Ryan

johnw
Champion III
Champion III

I suppose "distribution" is really the wrong word. I use it because that's what Publisher calls it. While you CAN email it to the users, or push the file to their PC if it's on a network, and that sort of thing, that's certainly not what we do here, and is probably not the typical approach. The "distributed" files still typically reside on the server.

Let's say you write an application for your customers to use, and maybe you have a hunded customers. You write the application once, loading ALL customer information into it. Then you tell Publisher to create a copy for each customer with ONLY their data on it. You now have a master file that NO customer can access, and a hundred different customer files. All of these files would typically still reside on your server, and each customer would only have permission to see "their" file. They wouldn't be able to see anyone else's file.

Without Publisher, using section access, I believe there would only be one file, rather than one file per customer. The QlikView application itself would control access, and only allow a given customer to see their own information, even though technically all customer data is in the application at the same time.

Not applicable
Author

Hi John,

Thank for you very much for your answer. I can already see how we can use publisher to simplify our reporting security access.

Cheers,

Ryan

rwunderlich
Partner Ambassador/MVP
Partner Ambassador/MVP


John Witherspoon wrote:As far as column-based security, yes, but perhaps trickier, such as linking the display of columns to the existence of particular rows of data. Someone may know of a better way


Section Access provides the OMIT keyword, which removes columns. Publisher data reduction does not provide such a straight forward way to remove columns that I know if.

-Rob