Apply AD groups with App Level Managment

[covenant_bi]

Hello, I created all the rules for app level management in the link here:
Video Link : 3762

Everything works as expected and I am able to control access to specific apps in streams.  However, I have found that once I tag an app with a custom property (as expected) the users in the stream lose access to the app until I apply the same custom property on the user record.  So it would appear that one would have to apply the setting at the user level and not the AD group level.  So if you had an AD group with 10 people and they needed access to that one app in the stream, you would have to go to 10 user records.   Is there a way to augment the rules in the video above to make exceptions for groups as well as users?

For reference:

Stream access rule :((user.group=resource.@Group))

App Default Rule:

(resource.resourcetype = "App" and resource.stream.HasPrivilege("read") and resource.@AppLevelMgmt.empty()) or ((resource.resourcetype = "App.Object" and resource.published ="true" and resource.objectType != "app_appscript" and resource.objectType != "loadmodel") and resource.app.stream.HasPrivilege("read"))

App Exception Rule:

resource.stream.HasPrivilege("read") and ((user.@AppLevelMgmt=resource.@AppLevelMgmt))

[balabhaskarqlik]

May be try this:

[Levi_Turner · Accepted solution]

Hey Ken,

Based on the logic of the rules, you have

(1) Stream: user.group=resource.@Group

(2) Stream > App Inheritance: resource.@AppLevelMgmt.empty()

(3) Exception: user.@AppLevelMgmt=resource.@AppLevelMgmt

As I understand it, when you apply the custom property to the app, the app isn't visible until the _users_ have a custom property assigned. This seems logical. The inheritance in (2) is triggered only when the custom property value is emtpy. If it's non-empty, then it would not be evaluated as true. Then from (3) you are requiring a strict match between the user's custom property and the app's.

If you'd like to use either custom property OR attritube from Active Directory then rule (3) can be adjusted to something like this:

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

It's not quite clear why you are using two different custom properties (AppLevelMgmt and Group) or what the underlying values are, but this style of or statement which can be evaluated as true in circumstances where the custom property or the group are present is the route.

Hope that helps.

[covenant_bi]

Levi,

That adjustment worked. I just had to adjust my Group custom property to include apps.  Then in the app I can have option to set access to an entire group or individual users as needed.  Much easier than setting app level access at each user.

As to why I am doing it this way, I was following the instructions in the Qlik video that I posted a link to in the OP.

The Group property is set to AD Group names so that I can set stream access at the custom property level by tagging the Stream with the AD group in the custom property rather than adding to a ruleset.  Does that help?  Is there a better practice than in the video?

Thanks again for being so helpful.

[Levi_Turner]

Glad to hear things are working now.

As far as best practice, there isn't a single answer because not all attribute stores (AD, ODBC, flat files, etc) have perfect information. In any ideal world the meta-data of users and their rights would be already managed in AD so that Qlik Sense can just leverage those existing attributes and processes for on/off boarding, but we do not live in an ideal world.

My approach would be as a general rule, custom properties are:

1. Perfectly fine to supplement meta-data
2. Ideally should be applied to a resource (e.g. an app, stream, etc) which then matches something from the attribute store

From (1), custom properties do require effort to create / assign / etc, so they should be thought of as a supplement, not a replacement.

From (2), when using custom properties against a resource matching against an attribute, you get a many to one relationship (i.e. apply to an app which means the 10 users with that attribute now see it).

I just generally wouldn't want to encourage people to have to do the same thing over and over with regularity. That makes using software a chore.

But again, this assumes some reasonable UDC source which can be leveraged.

Hope that clarifies things.