Restrict Log-in Capabilities Based on User

Let’s say, completely hypothetically, I have the following scenario:

  1. Operators at multiple sites and I want to restrict their access to only be able to log into sites for which they are the operator.
  2. It’s all in Vision
  3. I don’t see how Security Zones will work because everyone is accessing the sites remotely and computers get repurposed all the time.

I looked through the entire security section before I posted, so I’m sorry if I missed some glaringly obvious solution, but any feedback would be greatly appreciated.

Vision is good for this because each Project has a Project Property called “Required Client Roles” that allows us to require certain roles for a user to access a project. This would be how to approach this if you utilize the same User Source for all of your users across all sites. You would have to ensure each project had the correct required-site-specific-role, and you would have to ensure the users for each site are assigned that role.

If instead you want to manage this through separate user sources, you would just need to make sure each project has the corresponding user source for the associated site. Each user source would only contain the login info for the users at that site, and therefore couldn’t login to any projects that don’t utilize their user source (other sites).

2 Likes

@dhfrench there is a fair bit of work involved, but we use a SAML identity provider. In the SAML response we get a list of AD groups the person belongs to. There are site specific groups and we can tell the site by the URL. This is the basic method of doing what you are asking.

We also have line of site rules for control so we whitelist a certain group of machine names and resolve to that machine name with the IP address. That combined with SAML mentioned above provides fine resolution access control.

A key piece missing from Ignition is how to extract certain text from the SAML response. We do this with a custom scripting module which can be called from an expression inside the user attribute mapping. It looks like this, note we pass in the site address:

runScript("system.idp.processIdpResponse("+{idp-attributes:/saml2p:Response/saml2:Assertion/saml2:AttributeStatement/saml2:Attribute[@Name='adgroups']/saml2:AttributeValue/text()}+", system.net.getHostName())") 

We do this in vision and perspective and have spent a good amount of time on this topic. SAML is a reliable, easy to use system if its available to you.

Rgds,

Nick

2 Likes

@nicholas.robinson That sounds like a great way to handle the problem. Right now we are using LDAP instead of SAML because the operations managers wanted to be able to edit the roles without going through an IT department to modify the users. So, we have the AD-DB hybrid right now. Everything is still in development, so we have time to pivot. I will revisit the options.

@kvane Thank you very much for responding. So, for the launching projects in the designer, we do use the project properties permissions, for example, you have to have the role “designer” to view the project. I revisited the project properties interface in the designer the link to documentation you sent, and I’m struggling to see where I can apply a role-based restriction to logging into a vision client.

Thanks,
Doug

@dhfrench our company might have a few more tools than others but this is how that goes for us:

  1. we have a self help portal that we (designers) can create AD groups in, we control the naming convention which includes a site number (this is referenced later on in the SAML response).

  2. When we go to site to commission, we tell the site which are the AD groups and then we change the ownership of the group over to local IT, this is so they get the approval requests

  3. When people want to add an AD group to their subscriptions, they go to a self help portal, submit a request, which is then approved by their local leadership and IT.

So basically we set it up, and then the local site has the tools needed to manage it without our involvement.

Cheers,

Nick

1 Like

Are you on a much older version than 8.1? The Required Client Roles property is under Project Properties > Project > General:

Whatever roles are listed there (from the associated User Source) will be the only roles allowed to access the Vision Client for the project.