Qlik Community

New to Qlik Sense

If you’re new to Qlik Sense, start with this Discussion Board and get up-to-speed quickly.

Announcements
IMPORTANT security patches for GeoAnalytics Server available to download: READ DETAILS
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

Concrete answer on creating security rule at stream sheet level

Hello Guru's,

I would like to get concrete answer on this.

Problem: i have 10 active streams with already established security rules for them. I created new stream and would like to restrict access to certain sheets. For example :

StreamApp
sheets
test_user1
test_user2
test streamtest app101
test streamtest app210

So as you see i want both users to have access to the same stream and same app, but  restrict access at sheet level.

I read this:

https://community.qlik.com/thread/155799

which didn't provide an answer. I read many other posts, in which states, that security at sheet level is not possible in Sense (as of yet).

I understand i can create multiple apps and restrict access at app level, but before doing that i would like to see maybe there is a way to be able to do restrictions for 1 app.

Hope it makes sense

Waiting for your responses and thank you in advance

Oredas

1 Solution

Accepted Solutions
Levi_Turner
Employee
Employee

Yes, sheet level restrictions are possible.

In order to accomplish this, you will have to disable the Stream security rule which allows inheritance from the Stream to the App and to the App Objects and either rebuild it (1) or manually handle app level access.

(Both examples involve disabling the Stream rule and rebuilding it to fit the use case.

(1) e.g. (resource.resourcetype = "App" and resource.stream.HasPrivilege("read")) or ((resource.resourcetype = "App.Object" and resource.published ="true" and resource.app.@SheetLevelSecurity!="Yes") and resource.app.stream.HasPrivilege("read"))

-- Which ties into a custom property SheetLevelSecurity which is applied to Apps and has the values Yes or No.

or

(resource.resourcetype = "App" and resource.stream.HasPrivilege("read")) or ((resource.resourcetype = "App.Object" and resource.published ="true" and (resource.objectType= "sheet") and (resource.name!="Finance Dashboard" and resource.name!="HR Dashboard") ) and resource.app.stream.HasPrivilege("read"))

-- This refers to specific sheet names

This is not an elegant route which does have non-trivial maintenance costs.

View solution in original post

3 Replies
Levi_Turner
Employee
Employee

Yes, sheet level restrictions are possible.

In order to accomplish this, you will have to disable the Stream security rule which allows inheritance from the Stream to the App and to the App Objects and either rebuild it (1) or manually handle app level access.

(Both examples involve disabling the Stream rule and rebuilding it to fit the use case.

(1) e.g. (resource.resourcetype = "App" and resource.stream.HasPrivilege("read")) or ((resource.resourcetype = "App.Object" and resource.published ="true" and resource.app.@SheetLevelSecurity!="Yes") and resource.app.stream.HasPrivilege("read"))

-- Which ties into a custom property SheetLevelSecurity which is applied to Apps and has the values Yes or No.

or

(resource.resourcetype = "App" and resource.stream.HasPrivilege("read")) or ((resource.resourcetype = "App.Object" and resource.published ="true" and (resource.objectType= "sheet") and (resource.name!="Finance Dashboard" and resource.name!="HR Dashboard") ) and resource.app.stream.HasPrivilege("read"))

-- This refers to specific sheet names

This is not an elegant route which does have non-trivial maintenance costs.

Not applicable
Author

     Thank you Levi for the answer, i will mark it as correct, even though i will need time to test it. (need to find down time in case i mess up something for other streams, which I'm trying to avoid )

     If anyone else would like to shed some light on this subject, please feel free.

oredas

Levi_Turner
Employee
Employee

I can promise that it works in principle since I've done it as a demo in the past But the precise implementation may be tricky to get precisely right.