Hello everyone,
We want to develop an application that is placed on cloud that should analyze data coming from different plants connected with Gateway Network with a central Ignition on Microsoft Azure.
Each customer can have more than one plant, so we want to configure some users for each customer, after login into Ignition Perspective application, user has to select the plant he wants to see.
At this point, operator can see only certain views based on the selected plant.
Identity Provider is Ignition default.
I thought to do like this:
Create one role for each customer (That equals to the customers)
Create users for each role (Link the users with the customer)
Once operator logs into Perspective application we show the list of plants based on logged user role (only the plants for the logged customer has to be shown) and, when he selects the plant, only some views has to be shown based on selected plant.
Unfortunately this last point seems to be hard to set up, can anyone give me a help?
I like using a database user source for this because you can add a customer_id column to the users table. Then in the application, anywhere that you have customer-specific data you can display it based on the user's assigned customer_id.
You don't really need a database user source but I would recommend using a separate IdP that supports MFA especially if allowing control from the system. Then use a database as a lookup for their roles to limit the plants they can access. Just make sure the roles in the IdP follow some sort of standard naming so you can only filter plants based upon the company roles rather than any role.
The logic and filter based on role of the logged user to show only the specific plants already works.
The complication is that for each plant I want to enable or not views and component.
So is not sufficient make the logic only with role and user but also on the selected plant.
I thought to force security level rule based on selected plant and in the designer set the permissions on views and component but I dont know how to do this
You cannot base security on user-selectable values. Security can only be based on attributes out of the user's direct control, like roles and physical location.
You will have to create your own plant-selection state and drive visibility and/or component enables with bindings. Not with security settings.
I tried and if I bind session.auth to a label seems it is applied correctly
However if I set a view permission to have the same security level rule its not allowed the access
What I need is the possibility for the operator that logs into Perspective application to select a plant from a list (based on the customer, in my case I have set up roles like customers, so each customer can have some users) and then, based on the selected plant, show or not some views
Yes, but how are you defining which views each user can see? I'm assuming you're setting up roles based on what each group of users can see at each plant. This way let's say Alice can see plants A, B, and C as the supervisor role, but plants D, E, and F as only an operator or read only role that can both limit visibility of screens/areas, but also set restrictions on what actions they can take at each plant. Then maybe Bob can only see plants A, B, and C as an operator, but D, E, and F as supervisor. With roles similar to what I listed, you can do all of that.
Yes you are right but is it possible to set the role after the user select the plant he want to connect to?
I mean, when the application ss launched, the user has to login, based on the role of the user logged, I show the list of plant of the customer and AFTER select the plant I should switch the user to another role with the selected plant to show or not the views.
Seems I need two authentication steps, the first to detect the customer to show the plants, the second to see or not views based on selected plant or am I wrong?
No, you cannot. Roles are set from the user information at login, period, and constants after that. Store your plant selection in a session property and refer to it for all of your visibility and enabling requirements.
This is why I suggested your roles (role names) consist of both the plant and plant specific role in one role. In this way, when a user logs in and they select a plant, then you can check what roles they have for that plant and show views, etc. based on that list of roles.
The problem is that the user select the plant AFTER the login, so you cannot know the plant when the user is logging in, but only after he selects the plant from a specific view.
I think the only possibility is like @pturmel said, use a session custom property setting the selected plant and then build the logic to show or not views and to allow/deny components actions.
One more question: is it possible in this way, call a script that check the selected plant and, in a certain condition, deny the opening of a view? I was thinking to use system.perspective.navigate to a view like the screeshot instead the "normal" route to the target view
Build a "Hub" - a landing project accessible by any Authenticated user. From there, the list of plants (projects) would become visible based on the roles that user has.
Edit: I would prefer to know that I cannot click a button instead of clicking the button and be routed to a different page. Consider disabling the button (and adding a well-crafted tooltip) if a user does not have access.
A user can be denied access to a project by way of Project Properties --> Perspective --> Permissions.
A view can be restricted by right-clicking on the view (hint: with view opened) --> Configure View Permissions.
Edit: Create your Security Level Roles such that they are meaningful for your projects:
Plant 1
Area 1
Level 0 (View Only)
Level 1 (Basic Write)
Level 2 (Elevated Write)
etc...
Access to Project 1 (assuming 1:1 with the Plant 1 security level) would be granted to the Authenticated/Plant 1, which includes all sub-areas and access levels.
Access to pages could be restricted to specific areas.
Access to tags could be restricted to access levels.
Of course, the above is just an example. But, if structured correctly, a straightforward binding (no scripting required) should be able to correctly inform a user what they have access to.
Not automatically. You have to make sure all navigation checks for a valid view for your situation before opening the target view. It cannot be done after the fact, except via security, which cannot be adjusted after login.
For the fourth time, let me repeat: use bindings to control visibility and/or enables of the various components in your application, including navigation components, based on the post-login selection of the desired plant. Presumably stored in a session custom property.
