Best Practice for Component Based Security

Ignition
, ,
1

Currently in our perspective project, we're adding security to our HMI screens.

In our previous Vision projects, we implemented role-based security by controlling access on each individual component. Our ideal behavior is that controls remain visible, but users who aren't authorized can't interact with them.

In our Perspective project, we’re working with One Shot Buttons, Numeric Entry, and Buttons. We’re using the default UserSource and default IDP. Under Security Levels, I added our roles outside of the Roles security level so that I could define Security Level Rules in the IDP.

image
image140×134 2.31 KB

The reasoning behind this is to support hierarchical role detection, using this expression in the IDP:

containsAny(
    {user:roles},
    'Administrator',
    'Operator', 
    'Technician',
    'Engineer'
)

From there, I go into the custom properties of a component (like a button), and add:

  • Enabled (Boolean) This is bound to a tag that detects if the component should be usable based on the PLC.
  • MinSecurityRole (String) The string of the role/custom Security Level

Then I bind the props.enabled property like so:

{this.custom.Enabled} && isAuthorized(true, 'Authenticated/' + {this.custom.MinSecurityRole})

This works, but it’s a bit tedious to set up and maintain for each component. I’m wondering if this is the best approach for implementing component-based security in Perspective, or if there’s a better way or best practice for this.

I would appreciate any advice or suggestions.

2

Maybe make an array custom session property called isAuthorized, with an item pertaining to each security level. Have an expression binding on each item that is isAuthorized(true, 'Authenticated/AssociatedLevel').

Then, when configuring a button, you only need the enabled custom property, and the props.enabled property expression can be {this.custom.enabled} && {session.custom.isAuthorized.SecurityLevel}.

This removes one custom property per component. However, this might not be as straightforward to someone looking up what the security role requirement is for a component. They would have to edit the binding to see what level is being checked.

1 Like