Do not input private or sensitive data. View Qlik Privacy & Cookie Policy.
Skip to main content

Announcements
Qlik Open Lakehouse is Now Generally Available! Discover the key highlights and partner resources here.
cancel
Showing results for 
Search instead for 
Did you mean: 
micahsakata
Contributor III
Contributor III

Section Access by group and by user

I've implemented section access many times.  The way it typically works is by AD group or user.  This is determined by how you give access in QMC and how the security tables for section access are set up.  If you specify AD group access to the application, you specify access in the section access tables.  And vice versa if you want to specify users.  I'd like to do a mix of both but I don't think this is possible.  Here's my scenario:

Application XYZ.qvw is distributed in QMC by AD group "domain/XYZusers".

In the group, there are 3 users.

     user1 needs access to all the data

     user2 needs access to user2 data

     user3 needs access to user3 data

Normally, I would set up access by user instead of by group and assign the access on the section access tables by user.  However, in my actual situation, the list of users is very large.  I'd rather have all valid users added to a group for access to the application and manage row level security in the section access tables.  In fact, it would be easy to do this programatically/dynamically.

The issue I have is when you distribute by group, you authenticate to the application as that group, not as the user.  The only solution I can think of is to use the logon functionality to pass those credentials, but I would rather this be seamless to the user.

Any suggestions?

1 Solution

Accepted Solutions
Peter_Cammaert
Partner - Champion III
Partner - Champion III

I would like to add to Stefan's remarks that if you are using AD, authentication has already happened way before anyone ever touched QlikView. It 's the authorization part that you are managing in Distribution lists, License assignments and Section Access.

If you use all of these to manage authorizations for a single set of users, you're in for a lot of trouble with intersections of sets of such authorizations. For instance if you are using section access anyway, you could equally well distribute to all Authenticated Users, assign Document CALs dynamically (by enabling that weird seemingly useless check box) and perform all authorization management solely by way of Section Access rules (still using group names as well as user names). Which you state are easily implemented programmatically.

IMHO this saves you from a considerable amount of management hassle.

Just my 2cts.

Peter

View solution in original post

8 Replies
swuehl
MVP
MVP

I am not really sure I do understand:

"The issue I have is when you distribute by group, you authenticate to the application as that group, not as the user.  The only solution I can think of is to use the logon functionality to pass those credentials, but I would rather this be seamless to the user."

Isn't there a two step process involved:

- First reload and distribution process, done per group.

- Second, access of the distributed QVW by the user in AP.

I would have assumed that when you have both group and user lines in the section access table, QV will take the more granular lines to reduce the data.

If your user opens that QVW on the AP, does he really get authenticated only by the group?

Peter_Cammaert
Partner - Champion III
Partner - Champion III

I would like to add to Stefan's remarks that if you are using AD, authentication has already happened way before anyone ever touched QlikView. It 's the authorization part that you are managing in Distribution lists, License assignments and Section Access.

If you use all of these to manage authorizations for a single set of users, you're in for a lot of trouble with intersections of sets of such authorizations. For instance if you are using section access anyway, you could equally well distribute to all Authenticated Users, assign Document CALs dynamically (by enabling that weird seemingly useless check box) and perform all authorization management solely by way of Section Access rules (still using group names as well as user names). Which you state are easily implemented programmatically.

IMHO this saves you from a considerable amount of management hassle.

Just my 2cts.

Peter

micahsakata
Contributor III
Contributor III
Author

yes unfortunately, if you authenticate as a group, you also authenticate to the QV app as the group.  I did this experiment already.  adding both user and group to the Section access table gives access that is defined in the group.

micahsakata
Contributor III
Contributor III
Author

thanks peter.  this is a good idea except that the managers and user community would have a fit if they thought they had access to this app on access point.  I'd have to explain to a ton of people that security (for only this app) is handled within the application.  this is logistically not an ideal solution.  however, that would solve my issue.

Peter_Cammaert
Partner - Champion III
Partner - Champion III

So a solution would be to externalise the actual data (the ruleset, or - if you prefer a less bombastic definition - the names-and-link-field-values) for section access to a secured database table in a diofferent place entirely. The fact that it's still loaded by the same application and managed by the same people doesn't matter too much; it just boils down to "selling" this equally robust technique to management...

Best,

Peter

Peter_Cammaert
Partner - Champion III
Partner - Champion III

BTW I'm sure you already know that you can hide documents in the AP based on the authorizations defined by section access? If not, open your document in QV Desktop and enable Settings->Document Properties...->Server->Filter Accesspoint Document List Based on Section Access

Best,

Peter

swuehl
MVP
MVP

Micah Sakata wrote:

yes unfortunately, if you authenticate as a group, you also authenticate to the QV app as the group.  I did this experiment already.  adding both user and group to the Section access table gives access that is defined in the group.

Hi Micah,

could you post a sample / mock up script snippet how your section access table looks like?

It would be helpful if we can identify which user belongs to which group.

Thanks,

Stefan

micahsakata
Contributor III
Contributor III
Author

That totally works for me.  If I distribute to everyone but hide in AP based on section access, this completely solves my problem.  The proper user community can be responsible for giving access in the SA tables through a spreadsheet or something and people not in the SA tables won't see it on AP.  Brilliant!