Dynamic AD Security Roles

Ignition
, ,
1

Just putting a feeler out here for an issue I came across that I think I've found a somewhat elegant solution for, but wanted to get the community's feedback/opinions.

I've got an upcoming project where we'll be creating a standard project and templates that a company will begin using for all new plants going forward (and converting old plants over time). They use a centralized Active Directory with local domain controllers on each site. The problem comes in that they want to use security groups unique to each site, so for example operators at plant 1 will belong to sg_Plant1_Operators and plant 2 they'll belong to sg_Plant2_Operators, and plant 1 supervisors will be part of sg_Plant1_Supervisors. This is all out of my control, and if they were using Perspective with an IdP, I could map these roles over easily to generic security levels. With Vision, typically bindings use the hasRole('RoleName') function to determine if components are enabled, visible, etc.

To make things easier and adaptable, I've created a dataset memory tag Globals/SecurityRoles with 2 columns RoleName and SecurityGroup. So for the RoleName I'd have something like Supervisor and for SecurityGroup I'd have sg_Plant1_Supervisors. Then in place of hasRole('Supervisor') I'm using hasRole(lookup({Globals/SecurityRoles}, 'Supervisor', 'Supervisor')) to lookup the associated AD security group associated with a generic role name.

Does anyone see any red flags that could cause performance issues with possibly 10s to 100s of these running at once on screen changes? Any suggestions of other ways of handling this? I'd like to get this flushed out early on so I'm not going back through every template, faceplate, etc later and reworking all my bindings.

2

Do that in a Vision Client Tag expression. And reference the client tag wherever you need it. It will be very efficient, and place effectively zero load on the gateway.

1 Like
3

So are you saying create boolean client tags for each role (something like Role/Operator, Role/Supervisor) that get evaluated essentially once when they login, then just use that tag directly in the binding?

4

Yes. Tag bindings to Vision Client tags are truly local to the client and are therefore extremely efficient.

1 Like
5

Just did it, and it works very well (at least in the designer). Bindings are simple for most things since I can directly bind to the client tag, and anything that needs more than just a role I can use an expression with the appropriate tag/tags. Plus it's nice and clean (and readable).

6

For completeness, here's what the client tags look like for anyone else needing to implement this in the future:

image
image523×153 6.95 KB

Each tag is simply an expression like hasRole('sg_Plant1_Supervisor')

Then in bindings for a simple permission, you only need to bind directly to the Vision client tag. For more complex bindings, you can use the tag/tags directly in expressions.

For an extra added bonus, in my case, I'm naming my default tag provider the same as the plant name being used by the company in all the security groups, so my expressions can be like this:

hasRole('sg_' + {[System]Client/System/DefaultTagProvider} + '_Supervisor')

1 Like