Corso Systems

View Original

Identity Providers in Ignition

Note: As of Ignition 8.1, Identity Providers (IdP) can be used in Perspective, Vision, the Designer, and the Gateway Configuration page. In Ignition 8.0, Identity Providers are only available for Perspective. 

Prior to Ignition 8, user authentication options were limited to built in user sources and Active Directory—with some possible combinations of the two. In version 8, this functionality was expanded to include external providers using OpenID and/or SAML providers. So, you can now tie your Ignition users into your Google Workspace account for example, giving you single sign on (SSO) capabilities outside of Active Directory.

Beyond SSO capabilities, why would you want to use an external Identity Provider instead of the one built into Ignition?

Password Reset and Management

The first reason to use an external identity provider is to allow users to easily reset or manage their passwords. Sure you could build in a password reset system, but that requires more up front effort.

In any running Ignition system with users, inevitably someone will forget their password or need to change it. Without an external IdP (Identity Provider), someone will need to go to the Gateway Webpage, find the User Source, then the individual user’s account, and then update the password. This procedure also adds a little bit of a security risk as two people will now know the password—and it requires an additional run through the process for the user to change the password, assuming they have enough access privileges to the gateway to do this in the first place.

Identity Providers typically use a more secure process for password resets involving emails, and don’t require two people to know the user’s password. Users can also change their own passwords very easily.

Two Factor Authentication (2FA)

Most of the internet now allows 2FA as a rule. When you login on a new device, you’re probably familiar with seeing “How would you like to receive your code?” From here you will generally get a text message before being allowed to login.

In the original Ignition system it was possible to do 2FA, but required a great deal of extra development to put everything into place. 

Most external identity providers have 2FA as a built-in option, and will handle all of the work of implementing and managing it for you.

Decouple User Management from SCADA

Another major reason to use an Identity Provider over the built-in features in Ignition is to separate your SCADA system and your User Management interface. 

While you should be able to trust IT to use the Ignition Gateway or a Client to manage users,it does expose you to some risk of someone going into the gateway to add a user and accidentally turning off a PLC connection or deleting a database connection inadvertently or maliciously. 

Yes, you can build a project for user management in a client, but why go through the extra work of creating and maintaining it when you can use the built-in functionality of your identity provider?

Multi-Tenant Applications

Since Ignition is often the backbone of larger cloud-based systems, it becomes increasingly necessary to ensure security is maintained for access to the system as a whole—while also ensuring users can only see their data. 

For a cloud-based system supporting multiple end-users—potentially from different companies—using an Identity provider gives each group access to its own user source. It also allows you to expose your Ignition projects to many end-users, even if they are using different Identity Providers. 

For example, if we have a cloud-based Ignition Gateway and want to allow SSO from Google Workspace, Okta, Azure Active Directory, or any number of other systems, you can set up an inherited project for each IdP and give them access to only what they need without exposing the rest of your user base. This also allows the end-users to self-manage their accounts, saving you headaches and maintenance along the way.

Wrapping Up

Using Identity Providers in 8.0 was a no-brainer for Perspective projects. Now that Identity Providers are a first class citizen of security across the entire Ignition Gateway, you should consider them for any system you are deploying.

This applies to a system at a single site, all the way up to a cloud-based system supporting multiple enterprises around the world. 

The benefits heavily outweigh the small learning curve to setting up an Identity Provider, and with tools like Keycloak providing open source and self-hosted options at no cost, there is no reason not to set up an Identity Provider for your system.

Updated - 7/5/2022