AD idp / mqtt edge (Beginner)

Ben_Kelly · November 1, 2021, 3:36pm

Greetings,

First off I am new to igntion. I am a student and trying to get some projects set up for demo and learning purposes.
I have two qestions I would like some information or clarification on.

I am using Active directory to access the config gateway. Everything works as expected except the security levels.

If I use Active directory as the IdP to access the gateway it WILL pull the user and roles. When tested on the config it shows the roles correctly and the “security levels” the user is granted, however, the security settings for accessing the config page refer to security levels needed to access.

Using the , seperated roles does not seem to work. Using the structure “authenticated/role/ADAssigned” does work. This is the “security level” that is assigned to the AD user.

This does not match the security level permissions in the gateways security page. In fact there are NO security levels configured outside of the default. Doing so also does not allow me to add those “roles” to ne users created in a local IdP provider.

While my understanding of the difference is starting to come together - I am struggling to understand the relationship and how to use one or both either with AD or locally. The 8.1 documentation does not explain it to a degree that I am able to visualize.

I currently have an Ignition Server running on our network in good health(Alpha). I also have a raspberry pi running edge on the network.(Edge)

Alpha has Cirrus link mqtt engine, distributor, transmission installed and Edge has transmission installed.

Running wireshark on my laptop on the network (which has a designer installed) there is CONSTANT http/get requests going over the network between Alpha and Edge AND my PC asking for trial time remaindor.
I understand the need to update this between the running gateways and clients but how do I slow this polling rate down? It is eating a ton of bandwidth and boggin down Edge with requests and responses. (running on Pi)

Ben_Kelly · November 3, 2021, 3:32am

bump?

jspecht · November 3, 2021, 1:55pm

Welcome to the forum!

I can help you with the first item.

When you set up an IdP, you configure a User Attribute Mapper which tells the IdP how to extract the user’s ID, username, first name, last name, email, and roles from the IdP’s response. This is already configured for you if you are using the internal Ignition IdP. Once the IdP knows how to map roles, then for each authentication response that comes into Ignition from the IdP, the mapped roles will be added to the user’s security levels under the “Authenticated/Roles” node in the security level tree. For example, if the user has roles “X” and “Y”, then they will have security levels “Authenticated/Roles/X” and “Authenticated/Roles/Y”. These security levels that are granted to the user are scoped to the session that is bootstrapped from the IdP’s authentication response.

At this point, you’ve solved one half of the equation: “How Ignition derives the appropriate security levels for users who authenticate through your IdP”. The next half of the equation is setting up the permissions for protected resources in Ignition.

Let’s say you want to restrict the Gateway Web Interface’s Home, Status, and Config pages to only those users who have at least one of the two roles X or Y. In the Gateway Web Interface > Config > Security > General page, you would edit each of the following three settings:

Gateway Config Permissions
Status Page Permissions
Home Page Permissions

…with the following comma-separated security level paths:

Authenticated/Roles/X, Authenticated/Roles/Y

…and you would make sure that the radio option “Users must belong to at least one of these security levels in order to login…” underneath the security level paths input field is selected.

Once you save these settings, then from that point on, only users granted either of Role X or Y will be allowed into the Home / Status / Config pages.

There are many other areas of the product which use security level permissions, including Tag security as well as Perspective security. The Home / Status / Config pages are just one example.

Hope that clarifies a few things for you.

Ben_Kelly · November 6, 2021, 1:32am

All of that is very helpful! It is functioning as expected. However what is the relationship with the actual security levels configuration on the gateway? Is that only used for internal Idp mapping?

jspecht · November 8, 2021, 4:32pm

I think you are referring to the Security Level Tree that you can configure in Gateway Web Interface > Config > Security > Security Levels, right?

This security level tree defines the reference security level hierarchy for your entire Gateway. Usually its best to plan out your security levels early on, and what each security level will have access to. Any permissions configuration UI which uses security levels will use this security level tree as your “pick list” for ease of configuration. For example: if you go to the Designer and edit a tag’s permissions, the checkbox tree is based on the security levels you define in your Gateway’s Security Level Tree. Same for Perspective’s project permissions. Or try going to the security level rules or user grants configuration page for any of your IdPs - those security levels should be based on your reference security levels tree.

Just because a security level isn’t defined by your reference model doesn’t mean a user can’t have the security level. For example: there are special security levels underneath Authenticated/Roles/* and SecurityZones/* which are populated by the system based on what roles the user has or what security zones the user has. Similarly, you might have a security level rule defined for an arbitrary security level X/Y/Z, but if you delete X, X/Y, or X/Y/Z from your reference security levels tree while leaving the security level rule in place, it’s possible that users who satisfy the rule will still be granted X/Y/Z. You may also have tag permissions in place which still expects X/Y/Z even though you deleted it from your reference model.

Some day, the Gateway Web Interface will have a checkbox tree UI for each of its security level permissions to improve the user experience, but we just haven’t gotten around to building that UI in the Gateway yet, so it remains a basic text input where the user is expected to enter comma-separated paths to their security levels.