Streams, specific app access, single users & AD groups

[gramqlik]

Hi,

I know there are lots of posts on this sort of topic already, but rather than try and stitch together separate bits of of advice, I'm hoping someone can just steer me right, so I can ensure the correct Streams and Apps are visible to the relevant users, with the correct access level.

My current situation is as follows:

- About 30 data extract apps and 30 front end apps.

- The apps have been published to Streams based on department. I currently have 14 streams (7 for data extracts and 7 for front ends).

- 2 types of user initially:

* Developers - to be given access to specific Streams only (extract and front end) and every app within those streams. Create, Read, Update, Export Data, Duplicate rights.

* Testers - a handful of general users, to be given access to specific Streams (front end only) and only specific apps within those streams. Read and Export Data rights only.

- No users will have access to every app in a stream, even after testing is complete, so it is essential to handle user access at App level.

- Initially, I want to grant Developer and Tester access specifically by username. I have an AD group set up for each front end app, so once the testing is complete, the specified Testers will be replaced by the relevant AD groups. The Developers can continue to be specified by username.

I began trying to configure this in Qlik Sense, but ran into difficulty with the Testers access. Here's what I did:

1. Security Rules: Created a new rule for certain Developers to access 1 stream. Resource Filter = Stream_<streamID>, Actions as noted above, users specified by name. Works fine, developers can see all apps in stream.

2. Security Rules: Created a new rule for certain Testers to access the same stream, but with fewer permissions (Actions).

3. Need to limit the particular apps the Testers can see, so went to Custom Properties: Created AppLevelMgmt Set Resource Types = Apps and Users.

4. In the AppLevelMgmt custom property, set Values for several (front end) Apps.

5. Security Rules: Disabled the default Stream rule.

6. Security Rules: Duplicated the default Stream rule, renamed it to App Access. Added a Condition: @AppLevelMgmt .empty()). Ensured it was enabled. As I understand it, this means the user can now see the Stream, but no apps within it at this stage.

7. Apps: Edited each App. Under Custom Properties > AppLevelMgmt, applied the relevant Value created in step 4.

8. Users: Edited each Tester. Under Custom Properties > AppLevelMgmt, applied the relevant Values created in step 4.

The stream is visible (to a sample user) and he can see thumbnails for every app in the stream (not just those I created custom properties for). When he tries to open any app, it appears to be blank (no sheets). When he right-clicks a thumbnail, it does nothing, so can't Duplicate.

I also tried some additional steps:

9. Custom Properties: Created new property called StreamLevelMgmt, Resource Types set to Streams and Users.

10. Applied a value for the front end Stream.

11. Streams: Applied this Value to the Stream.

12. Users: Applied this Value to the User.

However, this made no difference, the user can still see all thumbnails, but can't open any.

So... can you tell me where I've gone wrong, and how to fix?

Thanks,
G

[andoryuu]

What does your @Group do?  That looks like it's already attached to the app - is that not the AD group?  If it's not, then I believe what you need is this:

((resource.stream.HasPrivilege("read") and (user.group = resource.@ADGroupReadRights )  and (user.@AppLevelMgmt=resource.@AppLevelMgmt  or user.group=resource.@Group )))

Keep banging away at it....

[gramqlik]

Right, I made a handful of changes, and I think I might be there now.

* Edited the AppAccessSpec rule - the @Group was erroneous - something I'd copied from another solution. So got rid of that, and added or user.group = @ADGroupRead to the Conditions. 'or' rather than 'and', so I can grat access either by specific users OR by AD group.

*  Edited the AppAccess rule - included resource.@ADGroupRead.empty (). I'm not sure if this is strictly necessary, but is in keeping with the existing resource.@AppLevelMgmt.empty ().

* Edited the ADGroupRead property - values now consist of all the relevant AD group names.

* Edited each front end App > Custom Properties to include the relevant AD group in the ADGroupRead property.

* Deleted the StreamAccessSpec rule and StreamLevelMgmt property, as unneeded.

* I've also made some AD group name changes and stuff to standardise things. I noted that after updating the list in the ADGroupRead property, the corresponding property on the App disappears and needs re-adding with its new name. Just something for me to be aware of, in case of future changes.

I've done some testing and I *think* it's all working as desired now. I'm going to do a full round of testing to ensure all bases are covered. Once confirmed, I'll add a reply to this thread, that lists the whole config as concisely as possible, just in case others might want to do something similar.

Thanks for your help, Andoryuu.

[andoryuu]

That's great to hear!  Doing custom security that doesn't require a lot of maintenance is a bear at first, but it's so, so, so worth it.  We are a 4 person admin, arch AND development team (with another three-person analytics team in our BI dept with us, but not admins) and a 3 environment, 14 server, 4800 user install.  Without automation, active directory, and self-service we'd have jumped off a bridge by now.

[gramqlik · Accepted solution]

Solution

In a nutshell, my requirements were to configure user access for 3 sets of users: Testers, Developers and AD Groups for general users.

• Testers - Read access to specific Apps in specific Streams. Solely used during the user testing phase, prior to Qlik Sense going live.
• Developers - Create, Read, Update, Delete and Duplicate access to Apps within specific Streams. My Developers will support specific business areas, so will not be given global access. I may also need to restrict which Apps they can access in a Stream.
• AD groups - Read access to specific apps in specific streams. We have an AD group in place already for every individual (Front End) App, as we used these for Qlikview.

To get the above working in Qlik Sense took a fair bit of research, advice, testing and tweaking. There are numerous threads and guides on how to configure Qlik Sense access, but none quite fit my scenario. So now that I have everything working, I thought I'd post my full config as a reply and accept it as the solution, as it may potentially help others in a similar position.

SECURITY RULES

• New Rule: AppAccess. Copy the existing default rule called Stream (I tend to use Snipping Tool to screenshot). This will be the new rule for Streams without App level management. In the Conditions, before the "or", add the following: and resource.@AppLevelMgmt.empty() and resource.@ADGroupRead.empty())

• Amend Rule: Stream. Set Disabled to Yes. We no longer need the default rule, as we now have AppAccess.

• New Rule: AppAccessSpec. This rule enables App-level access to users and AD groups.
  • Resource filter = App*
  • Actions = Read
  • Conditions = (resource.stream.HasPrivilege("read") and ((user.@AppLevelMgmt=resource.@AppLevelMgmt) or (user.roles!="Developer" and user.group = resource.@ADGroupRead)))

•  New Rule: AccessDev. This is to apply advanced access for Developers, in particular, allowing them to duplicate and work on apps.
  • Resource filter = App*
  • Actions = Create, Read, Update, Delete, Change owner, Export data, Access offline, Duplicate
  • Conditions = (user.roles="Developer") and ((user.@AppLevelMgmt=resource.@AppLevelMgmt) or (user.group = resource.@ADGroupRead))

• New Rule: AccessDevDLE. This rule is necessary to allow the Developers to view and edit scripts, as this is not enabled by default for security purposes.
  • Resource filter = App Object_*
  • Actions = Read, Update
  • Conditions = ((resource.objectType="loadmodel" or resource.objectType="app_appscript")) and resource.app.HasPrivilege("read")

• New Rule: AdminPublish. Copy the existing default rule OwnerPublishDuplicate. I only want to allow the Root Admin to Publish apps to live streams at present. Set the Conditions to ((user.roles="RootAdmin")).

• Amend Rule: OwnerPublishDuplicate. Set Disabled to Yes. We no longer need the default rule as we now have AdminPublish. Developers are already granted Duplicate access by the AccessDev rule.

• New Rules: One for every stream. In my environment, I have two Streams for every department, one for Extracts and one for Front Ends. For example: Access HR EXT and Access HR FE.
  • Resource filter = Stream_<Stream ID>
  • Actions = Read
  • Users = Here I am specifying the Developers by user.name in both the EXT and FE rules, and the Testers by user.name to the FE rule only (they don't need to see Extract Apps).

Once user testing is complete, I will remove the Testers from these rules, and replace with the relevant AD groups.

• The Stream ID can be found by opening the Stream in the QS Hub and taking the last part of the URL, e.g. https://<your server>/hub/stream/1a23456-b789-1a23-4567-c891d23e4f56

CUSTOM PROPERTIES

• New CP: AppLevelMgmt.
  • Resource Types = Apps, Users
  • Values = Currently, I have one CP Value for every Front End App, and one CP Value covering all Apps in each Extract Stream. I’ve just used recognisable names for these values, e.g. HR Holidays, HR Personnel, and HR EXT.

Should I need to, I could replace the Stream-wide CP Value HR EXT with CP Values for each individual Extract App (HR Holidays EXT, HR Personnel EXT). This would allow me to specify exactly which Extract Apps Developers can see. However, this isn’t necessary for me at the moment.

• New CP: ADGroupRead.
  • Resource Types = Apps
  • Values = One for every AD group that will be used to grant App access to regular users. I’ve named these Values exactly the same as the AD groups themselves, as the Group needs to match the CP value to allow the User access. E.g., say we have an AD group called ABC_HR_Holidays, then I’ll have a Value under the ADGroupRead property called ABC_HR_Holidays.

APPS

• Amend Front End Apps. Under each App > Custom Properties > AppLevelMgmt, set it to the relevant CP Value added in the AppLevelMgmt Custom Property. E.g., in my Front End App called Human Resources Holidays, the AppLevelMgmt Custom Property Value = HR Holidays.

• Amend Extract Apps. Under each App > Custom Properties > AppLevelMgmt, set it to the relevant “EXT” value above, so for my two Extract Apps called Human Resources Holidays Extract and Human Resources Personnel Extract, I'm using the same AppLevelMgmt property = HR EXT.

• Amend Front End Apps. Under each App > Custom Properties > ADGroupRead, set it to the AD group name, e.g. ABC_HR_Holidays.

• We only grant access to Extract Apps to specific Developers, not to general users and not by AD group. So, we don’t need to update the ADGroupRead Custom Property on any Extract Apps.

USERS

• Amend all Users who are specified by name. I'm granting permission by name to Developers (permanently) and Testers (temporarily). For each of these users, under Custom Properties > AppLevelMgmt, I enter all relevant values. So, I may have a Tester with HR Holidays and HR Personnel, and I may have a Developer with those two plus the Extract property HR EXT.

• Amend Developers only. Add the Role = Developer. This was specified within the Security Rule AccessDev, granting these users CRUD access.

USER DIRECTORY CONNECTORS

• We have an AD group for each Qlikview Front End App, and will be re-using these in Qlik Sense.

• Our AD groups initially included our Developers. I could grant the Developers CRUD access by including the relevant Custom Property on the User along with the Developer role. However, when I excluded the CP, it would still grant them Read access to all Apps in any Stream they had access to, due to the other Security Rules in place.

• To circumvent this unwanted Read access, I removed the Developers from the AD groups. QS access will be granted to Developers by specifying their user.name, and to general users by their AD group membership.

• After updating the AD Groups, I went to User Directory Connectors, selected my LDAP connector and clicked Sync.

LICENSE MANAGEMENT

• License Management > Professional / Analyser access allocations. Here I granted a license to each of my Developers and Testers, so they can do their jobs before Qlik Sense goes live.

ADDITIONAL NOTES

• If you change a Custom Property (e.g. renaming it), it will disappear from the App and any specified Users, so be sure to reapply them. I don’t think the same thing happens when renaming Security Rules, but it’s always worth checking!

• Audit is your friend. It helped me many times during this, to confirm AppLevelMgmt properties had been applied to users, to compare permission levels for Developers and Testers, to ensure the Developer Role had been correctly applied, to check that the correct Associated Rules were triggered by particular users and AD groups, etc. Audit made me aware that the OwnerPublishDuplicate rule existed and was granting Developers Publish rights, which I needed to disable.