# Best Practice for Component Based Security

**URL:** <https://forum.inductiveautomation.com/t/best-practice-for-component-based-security/107722>\
**Category:** Ignition\
**Tags:** vision, ignition81, perspective\
**Created:** [June 24, 2025, 3:27pm UTC](https://forum.inductiveautomation.com/t/best-practice-for-component-based-security/107722 "2025-06-24T15:27:42Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![RD17](https://avatars.discourse-cdn.com/v4/letter/r/c0e974/32.png) [@RD17](https://forum.inductiveautomation.com/u/RD17)\
**Post date:** [June 24, 2025, 3:27pm UTC](https://forum.inductiveautomation.com/t/best-practice-for-component-based-security/107722/1 "2025-06-24T15:27:42Z")

</div>

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](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/8/28aa4ae865cda6a4f9f538e6d1b2075e039a4ee0.png)  
The reasoning behind this is to support hierarchical role detection, using this expression in the IDP:

```python
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:

```python
{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.

---

<div class="post-metadata">

**Author:** ![ryan.white](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan.white/32/73193_2.png) [@ryan.white](https://forum.inductiveautomation.com/u/ryan.white)\
**Post date:** [June 24, 2025, 3:59pm UTC](https://forum.inductiveautomation.com/t/best-practice-for-component-based-security/107722/2 "2025-06-24T15:59:53Z")

</div>

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.