Understanding User Roles and Security Levels in Ignition: A Practical Example

Ignition
1

I wanted to share some insights and seek clarification on the topic of User Roles and Security Levels in Ignition, as I have found it to be quite confusing. I hope this example will help illustrate the challenges I've encountered.

Access Matrix Example

Here is a simplified access matrix for my project:
Two role created:

  • OperateGroup1
  • OperateGroup2

Two user created and assign to sepecific group.

  • User1 ： Assign to Role: OperateGroup1

  • User2 ： Assign to Role: OperateGroup2

  • View1 Page: All users can load the view. No specific view permission is set up.

    • View1 Button: User1 can operate the button. The button's enable binding is set up with the isAuthorized expression.

  • View2 Page: Allow User2 can load the view, but User1 cannot. I try to use View permission , but realized it only allows selection from security levels, which I initially did not plan to use.

The Confusion

When using the isAuthorized expression, I noticed that I have to include the prefix Authenticated/Roles/ in the expression like this: isAuthorized(true, 'Authenticated/Roles/OperateGroup1'). However, I did not create this security level explicitly. This raises a few questions:

  1. Why is the Authenticated/Roles/ prefix necessary?
  • It seems that without this prefix, the isAuthorized expression does not work as expected. Is this a default requirement in Ignition?

image
image1822×843 97 KB

  1. Creating Security Levels:
  • When creating security levels, I noticed that I cannot select from existing user roles. The creation of rules seems arbitrary and not directly linked to user roles. Is there a relationship between user roles and security levels that I am missing?
    Refer to below screenshot, I haven't create any security level yet.
    image
    image1713×838 44.7 KB

Seeking Clarification

I would appreciate any insights or explanations from the community or the Ignition team regarding the following:

  • The necessity and function of the Authenticated/Roles/ prefix in the isAuthorized expression.
  • Best practices for setting up security levels and their relationship with user roles.
  • Any tips or resources that could help clarify the setup and management of user roles and security levels in Ignition.
2 Likes
2

This is a good observation and question, the confusion is mainly coming from the fact that Perspective is not actually using your User Source, rather Perspective is using an internal Identity Provider which has a source of: your internal User Source. Perspective is based entirely on Identity Providers, and that means Security levels are the attribute we build logic against for Perspective.

"Authenticated/Roles/OperateGroup1" is a String representing a Security Level Path, since you are using an internal User Source the string defaults to: Authenticated/Roles/{roleName} for the roles you create in the User Source. This is not the same as adding Security Levels to the Gateway webpage.

It may seem like I have described a connection that is directly User Source > IdP, but in reality an Identity Provider should be considered a 3rd party source of user information. By default, Ignition has no reference to the Security Levels that a connected Identity Provider has (this is even more apparent when connecting a 3rd party Idp, it is less clear when using an internal source).

If you refer to Identity Provider Authentication Strategy in the User Manual you will find an image that shows the overview of the Identity Provider connection to Ignition.

image
image541×327 38.6 KB

In this image you can see that the IdP is distinct from your server, when you use an internal User Source you are essentially forcing Ignition to consider its own User Source data as incoming IdP data. It still uses this same flow, meaning on step 3 Ignition sends the login information to your internal IdP and in step 6 it returns with your access token which includes the Security Levels. You can see the token by using the "test login" button on the Identity Provider in the webpage, and is a good way to confirm things are working as you expect on initial connection.

Since IdPs are separate from Ignition it will never generate Security Levels for you automatically, so you must create them even for internal User Sources. The user manual has most of the information you need. Generally the steps for IdP security setup are: connect Idp > setup User Attribute Mapping if needed > setup Security Levels > setup User Grants if needed.

1 Like