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.
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.
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.
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.
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.
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.
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:
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).
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.
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.
