Security Settings Combination in Perspective

Ignition Early Access
1

Hi,
In the Security Setting of event script in perspective we can only choose between two option:

image

So what happened if I want to limit user by combination of those option.
Like certain security zone AND at least one of the chosen roles at the same time(not all selected roles).
For example roles Admin OR Operator issue command if they exist in Control Room Zone but user don’t need to have both admin and operator role at the same times.
roles(Admin OR Operator) AND zones(Control-Room)

2

You could create a custom security level rule for more complex logic

3

As I understand it, security zones are about physical locations, e.g. a group of IP addresses. Security levels under "Authenticated" are all about the people logging in. With these two being orthogonal it would really only make sense that you need both security levels ("all of"). Otherwise, any login would defeat the need for the zone, thereby making the zone useless.
An exception is when you ONLY use zones, in which case "any of" can still make sense.
So if you want to use zones and roles, you have the "all of" setting, which then means that you need an additional role for each combination of basic roles.
For instance, keeping it simple, we have "administrators" and "operators", then we also need a role "administrators and operators". Otherwise we could not make the function available to both administrators and operators, because typically operators would not be administrators, and if we tick the boxes of both basic roles, then the "all of" rule is going to stop the operators using it.
This gets out of hand pretty quick if you consider more basic roles.

I think Inductive Automation has made a mistake with this design. Zones and roles are not both "levels", they are separate concepts and the logic needs to be defined in accordance. It should be: any or all of the security zones AND/OR any or all of the roles. It's slightly more complicated with regards to the custom levels, but that's where I think the concept needs to be re-thought.

What am I missing?

4

This isn't true. I can make a Security Zone named "Plant" based strictly on IP to restrict access to a subnet of my organization. I can also make a Security Level for my Operators, where I dictate any user from my facility receive that Security Level.

With these two potential requirements in place, ready to use, and applied as requirements, there are two different potentialities - both of which are valid and have realistic use-cases:

  • All of: Someone from my facility must be logged in AND must be on a machine which is part of the local subnet.
  • Any of: Someone from my facility must be logged in (but they could be located off-site - like a remote worker) OR any machine from the local subnet could have access - even if no user is logged in.

Now, maybe this doesn't suit all needs. Suppose I want to allow all logged in facility workers but I want to require they be on-site, AND I want to allow Management, who might not be on-site. At this point you just need to create a Security Level called something like "On-Site Operator" where that Security Level is a combination of the rules you created for Operator and the Security Zone. Then you can specify the Security Settings for the component as requiring "any of" the "On-Site Operator" or "Management" Security Levels.

5

Thank you cmallonee. I agree with you, those are two valid examples.
But at the same time I feel my original comment is correct. Once you go beyond those very simplistic cases you need to start making security levels for all kinds of combinations of other security levels.

After looking into the issue a while longer, what I am settling on is the use of "isAuthorised" to achieve the flexibility in logic. This can be applied to all kinds of properties, instead of just where Ignition has permissives. So this is quite flexible and should work for more cases.