# Perspective Security Level Rules **URL:** \ **Category:** Ignition\ **Tags:** perspective, ignition83, security\ **Created:** [March 4, 2026, 4:35pm UTC](https://forum.inductiveautomation.com/t/perspective-security-level-rules/114318 "2026-03-04T16:35:19Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![Matthew\_Automation](https://avatars.discourse-cdn.com/v4/letter/m/a4c791/32.png) [@Matthew\_Automation](https://forum.inductiveautomation.com/u/Matthew_Automation)\ **Post date:** [March 4, 2026, 4:35pm UTC](https://forum.inductiveautomation.com/t/perspective-security-level-rules/114318/1 "2026-03-04T16:35:20Z")
Hello My goal is to have my ignition 8.3 perspective project allow View Only (public) access, and ‘Admin’ access. If the user is signed in (Authenticated) but does not belong to ‘Admin’, I want to reject the user’s login. I am ok with public access or Admin access. I have an Identity Provider set up pulling from an Active Directory user source. I built an ‘Authenticated / roles / Admin’ security level to match the ‘Admin’ role returned by the active directory. I have used idp / Test Login to verify the ‘Admin’ role is in the Idp Response Data roles list and the Security Level Grants tab under Public / Authenticated / Roles / Admin. I build a security level at Authenticated / AllowAccess. For the idp security level rule, I set the rule to containsAny({idp-attributes:roles}, 'Admin'). I do not see the AllowAccess security level under the roles or security level grants for the test login, and I do not see it listed in the perspective session information. My plan was to expand this rule to be ‘contains Admin or does not contain Authorized,’ but cannot seem to get either one of those to work. Does anyone have any ideas? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 4, 2026, 4:54pm UTC](https://forum.inductiveautomation.com/t/perspective-security-level-rules/114318/2 "2026-03-04T16:54:01Z")
Your goal seems non-intuitive to me. Consider just using the Admin role to control write access. Simply treat non-admin login as read-only, just like public. ---
**Author:** ![Matthew\_Automation](https://avatars.discourse-cdn.com/v4/letter/m/a4c791/32.png) [@Matthew\_Automation](https://forum.inductiveautomation.com/u/Matthew_Automation)\ **Post date:** [March 4, 2026, 5:06pm UTC](https://forum.inductiveautomation.com/t/perspective-security-level-rules/114318/3 "2026-03-04T17:06:10Z")
Unfortunately, this is an application requirement, though I would agree. I am planning on pushing back against this, but I imagined it would be possible to implement. ---
**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\ **Post date:** [March 4, 2026, 6:30pm UTC](https://forum.inductiveautomation.com/t/perspective-security-level-rules/114318/4 "2026-03-04T18:30:38Z")
There’s no way to just bail-out of the login process. The result is always going to be that the user logs in and creates a new session with their credentials. In theory you could make a check in the Session Startup script against the roles of the user and force a logout in the event they don’t have admin privileges. I agree with Phil though the approach I just offered is inadvisable and you should never force-logout a user based on a lack of permissions; their permissions should dictate what they can do within the project. If you need to prevent users from seeing the project altogether based on some restrictions, there are alternative mechanisms for managing that. ---
**Author:** ![Matthew\_Automation](https://avatars.discourse-cdn.com/v4/letter/m/a4c791/32.png) [@Matthew\_Automation](https://forum.inductiveautomation.com/u/Matthew_Automation)\ **Post date:** [March 4, 2026, 7:00pm UTC](https://forum.inductiveautomation.com/t/perspective-security-level-rules/114318/5 "2026-03-04T19:00:08Z")
I understand there is no way to bail out, and I agree it is not good to force a log out. The issue is this new requirement that users without ‘Admin’ role cannot sign in, but there also must be a Public View Only access so I cannot simply restrict access to only the ‘Admin’ role. There is a way to restrict login access for a project based on security levels [project properties / perspective / permissions]. So, if I can build a security level with a rule like [!containsAny({security-levels}, 'Authenticated') || containsAny({idp-attributes:roles}, 'Admin')], this should cover both a session that is not signed in and an Admin session. This was not working, so currently my goal is to simplify and get a security level rule working to assign users with ‘Admin’ to this new security level. This rule expression [containsAny({idp-attributes:roles}, 'Admin')] is not assigning the user to the new security level, even though I know the user has the ‘Admin’ role. I believe I am not understanding how to use a Security Level Rule. I have watched the video, which helped get me to this expression, but it does not explain how to then use the rule. ---
**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\ **Post date:** [March 4, 2026, 8:59pm UTC](https://forum.inductiveautomation.com/t/perspective-security-level-rules/114318/6 "2026-03-04T20:59:14Z")
> [@Matthew\_Automation](#): > > There is a way to restrict login access for a project based on security levels [project properties / perspective / permissions]. Not that I am aware of. Where is this mechanism you are attempting to use? While Perspective projects have security settings in place, they are there to restrict _access_ - not authentication. Again: once a user begins the login process, the process will end in one of several ways: - The user will succeed with valid credentials. - The user will have invalid credentials and eventually be forced back out of authentication. - The user will opt to back out of authentication of their own accord. There is no mechanism I am aware of to prevent successful authentication with valid credentials. An alternative approach might be to use a different Identity Provider for this project, where only your “Admin” users have credentials within this secondary provider. In this scenario, only they could successfully log into the project, and other users would still be able to view the project - but not log in. Unfortunately, this approach would require you to maintain two different identity providers. ---
**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\ **Post date:** [March 4, 2026, 9:46pm UTC](https://forum.inductiveautomation.com/t/perspective-security-level-rules/114318/7 "2026-03-04T21:46:38Z")
I agree with others above. A login experience should be intuitive. Reference other public-facing websites as a model for your login (Google, Microsoft, …). I would either: 1. Enforce “Authenticated” in order to access the project at all (preferred, where any authenticated user is configured for read-only access by default, those with specific roles will be elevated). 2. Allow “Public” (unauthenticated) access to the project but add tag provider + tag security to ensure that only “Authenticated/Admin” has access to write. If you wish to reject a user’s login when they are not a member of a specific group, then you should configure the filter on your AD source to be limited to members of a specific group, whereby other members will not be able authenticate at all - and they’ll be forced to back out of authentication. For reference: > [@Active Directory LDAP User Search Filter - Filter out memberOf specific group(s)](https://forum.inductiveautomation.com/t/active-directory-ldap-user-search-filter-filter-out-memberof-specific-group-s/29228/3): > > Yes, hopefully this helps you and others. The method that we needed to use was the User List Filter along with the User Listing Base and User Search Filter. It’s helps to get the DistinguishedName of the path to the OU you want to use (Like Sysinternals AD Explorer). I will describe the filters strings below. #Use to narrow down which Organizational Units to search for. The more you use, the faster the audit roles will be. Being too broad can make it slower. To do this you combine your OU’s… ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [March 5, 2026, 2:42am UTC](https://forum.inductiveautomation.com/t/perspective-security-level-rules/114318/8 "2026-03-05T02:42:25Z")
> [@Matthew\_Automation](#): > > The issue is this new requirement that users without ‘Admin’ role cannot sign in Easy, just remove their logins altogether 🙂 ---
**Author:** ![Matthew\_Automation](https://avatars.discourse-cdn.com/v4/letter/m/a4c791/32.png) [@Matthew\_Automation](https://forum.inductiveautomation.com/u/Matthew_Automation)\ **Post date:** [March 5, 2026, 1:28pm UTC](https://forum.inductiveautomation.com/t/perspective-security-level-rules/114318/9 "2026-03-05T13:28:37Z")
> [@Chris\_Bingham](#): > > If you wish to reject a user’s login when they are not a member of a specific group, then you should configure the filter on your AD source to be limited to members of a specific group, whereby other members will not be able authenticate at all - and they’ll be forced to back out of authentication. Awesome idea! I am going to give this a shot today. Thanks for the suggestion. ---
**Author:** ![Matthew\_Automation](https://avatars.discourse-cdn.com/v4/letter/m/a4c791/32.png) [@Matthew\_Automation](https://forum.inductiveautomation.com/u/Matthew_Automation)\ **Post date:** [March 5, 2026, 4:03pm UTC](https://forum.inductiveautomation.com/t/perspective-security-level-rules/114318/10 "2026-03-05T16:03:04Z")
Unfortunately, the users are not directly assigned to the ‘Admin’ role. Instead of ‘memberOf’ they have the ‘member’ property. Based on what I have seen, the AD User Source cannot filter on indirect groups. We cannot make changes to the AD, so we are planning on going forward by signing the user out if no ‘Admin’ role. Thanks for all the suggestions though. ---
**Author:** ![Nol](https://avatars.discourse-cdn.com/v4/letter/n/8e8cbc/32.png) [@Nol](https://forum.inductiveautomation.com/u/Nol)\ **Post date:** [March 5, 2026, 6:24pm UTC](https://forum.inductiveautomation.com/t/perspective-security-level-rules/114318/11 "2026-03-05T18:24:08Z")
I guess I don't fully understand the requirement. Like if I go to the site, as a rando without signing in I can view the project in read only mode. But if Fred the operator logs in, you want him to get access denied and not be able to see anything at all? Why can't Fred simply get nothing for logging in and still just be treated as part of the read-only public access? If you go to that route then if they're admin - enable controls if they're anything besides admin - read only. ---
**Author:** ![Matthew\_Automation](https://avatars.discourse-cdn.com/v4/letter/m/a4c791/32.png) [@Matthew\_Automation](https://forum.inductiveautomation.com/u/Matthew_Automation)\ **Post date:** [March 5, 2026, 6:39pm UTC](https://forum.inductiveautomation.com/t/perspective-security-level-rules/114318/12 "2026-03-05T18:39:09Z")
Sounds like you fully understand the situation to me ¯\_(ツ)\_/¯