When I set my Identity provider as the logon source in ignition for my vision clients how do I use the security levels for security on the screen. In order to enable/disable buttons etc. I used to use the Roles in the user source, but now I want to be able to use the Security Levels.
Vision does not support security levels in a first-class way. Vision’s access control model is based on roles and security zones. When you authenticate into Vision using an Identity Provider, the security levels are converted into roles and zones from the
SecurityZones/... security levels, respectively. As long as you have your Roles user attribute mapper configured correctly for your IdP, you should be able to use roles and zones in Vision.
Thanks for that info. I can’t find great documentation for how to set up that User attribute mapping. Everything looks like it needs to parse the response document but my security levels are set up in the user grants section. Is there a way to set up the role mapping based off the Security Zones?
Is it not possible to map a Level to a Role in Vision manually though?
For example, the blue levels shown are setup with Security Level Rules that work as expected.
However it sounds like Vision can’t utilize these Security Levels. So I tried to create equivalent security levels that can be mapped to roles as shown in red.
Is the only way to actually map these levels to the user roles by actually checking the box in the User Sources editing screen for each user?
From an IdP perspective, the Roles attribute mapper is responsible for determining which roles a user has. In most cases, you’ll want your mapper to map the roles from the IdP response object, effectively delegating role assignment to the IdP. In the case where the IdP is an internal Ignition IdP, the IdP response object is an OIDC ID token with a “roles” claim which is populated from the roles assigned to the user from the user source profile which the internal IdP’s settings points to. The user-to-role assignments managed by each user source profile is configurable in the Gateway Web Interface > Config > Security > Users, Roles which is the editing screen that I believe you are referring to.
If you want, you could move some of your logic from your security level rules to your roles attribute mapper if you want to derive which roles a user has using more complex logic driven by an expression, rather than simply relying on whatever the IdP tells you the roles should be. Keep in mind that attribute mapping happens before user grants and security level rules are invoked. So you wouldn’t yet know at the time the user attribute mapper is executing which levels the user has.
Thanks, yes i don’t think editing the role mapping is the route we want to go down. It is best to leave that mapping as direct i think, from the User Source through to the IdP.
Especially since the attribute mapping happens before Security Level rules are evaluated, as those are what i need to check anyway.
Does the Vision client login settings Authentication Strategy have anything to add to this, or is that simply defining how the login for the client works? That won’t allow us to utilize Security Levels any different in Vision Clients i presume?
The authentication strategy dictates how the Vision Client authenticates users, but the Vision authorization model is based on an RBAC model regardless of authentication strategy. Vision was around long before Security Levels, so refactoring it to be Security Level aware is quite a risky change. I won’t say that we will not ever consider such a change, but it’s not even on our radar as of right now.
Ok thanks, understandable. Will find another way to achieve what we need. Cheers