An Identity Provider (IdP) offers a way for users to log in to Ignition using credentials stored outside of Ignition. An IdP creates, maintains, and manages identity (login) information while providing authentication services to Ignition. This provides a secure login that allows Ignition to use SSL and two-factor authentication (2FA).

Identity Providers (IdPs) offer user authentication as a service. An IdP creates, maintains, and manages identity information for principals while providing authentication services to relying party applications within a federation or distributed network. Authentication of the user is handled by the IdP. Ignition can connect to these three different types of IdPs: 

Your organization's IT may have some sort of existing integration with an Identity Provider. Some popular Identity Providers are listed below. 

IdPs are set up at the Gateway level. Security Levels are also set through the Gateway. The Security Levels enable you to define a hierarchy of access inside a Perspective Session.

The following feature is new in Ignition version 8.1.0
Click here to check out the other new features

As of release 8.1, Identity Providers can also be used in the Vision module, the Designer, and on the Gateway.  The Identity Provider strategy redirects the user to their IdP in their web browser in order to authenticate. The System Identity Provider setting controls which Identity Provider the user is redirected to.

Note: If your browser is not supported, you will get an error message.

On this page ...



Identity Provider Authentication Workflow

The following diagram illustrates how IdP authentication works.

  1. User make a login attempt to the Gateway, a Perspective Session, or a Vision Client.
  2. Ignition sees that IdP authentication is required.
  3. Ignition redirects the User to Identity Provider for authentication of their credentials: 
  4. IdP Authenticates the User: The IdP prompts the user with a security challenge, such as requesting a username and password. The extent of the challenge depends entirely on the provider, but many providers may offer support for multi-factor authentication (MFA).
  5. User Responds: The user correctly responds to the security challenge.
  6. Redirect back to Ignition: If the IdP successfully validates the user, it will redirect the user back to the Perspective Session. Some IdPs may have an additional workflow they will guide the user through, such as re-verifying an email address or replacing an expired password. The IdP will also return information about that user to the Session. This provides some context about the user that the Session can use to assign Security Levels. 
  7. Update the User's Security Level: Once back at the session, the user will be mapped to the specified Security Level, giving the user access to the restricted action. 


Using Identity Providers

The first step in using Identity Providers is to configure them. For the steps for configuring Internal Ignition IdP, OpenID Connect 1.0, or Security Assertion Markup Language (SAML), go to  Configuring Identity Providers.

Once an Identity Provider has been configured, there are a few things that can be done to test and adjust how it works. You can map the attributes that are returned in the IdP response document to more familiar user properties that are available to use within the project. You can add rules to custom security levels that determine when a user falls into the level. Overrides can be given to users in the form of User Grants, so that they are granted certain security levels regardless of the rules. Finally, you can test out the IdP by logging in with a user to confirm what is returned in the response document.


Auth Token Connection Recovery

The following feature is new in Ignition version 8.1.24
Click here to check out the other new features

After logging into the IdP, a special auth token is generated with the session on the Gateway and is saved in the Designer and Vision Client instance memory after authenticating with an IdP. If a connection is lost and later recovered, Designers and Vision Client instances may securely resume their sessions without having to completely restart by passing the Gateway a valid auth token. Note that auth tokens are not included in Gateway Backups. Any existing auth tokens are cleared when a Gateway Backup is restored.

You can further configure auth tokens by adjusting settings that control the auth token lifecycle. To see these settings, make sure Identity Provider is selected as the Authentication Strategy as these settings do not apply to the Classic Authentication Strategy.

  • User Inactivity Timeout: The number of minutes which must elapse before expiring a user's auth token due to inactivity caused by a disconnected session. Must be greater than zero. Default: 10 minutes.
  • Time-To-Live (TTL): The maximum number of minutes a user's auth token may exist before it expires. If set to any number less than or equal to zero, auth tokens will not expire, as long as the auth token has not expired due to inactivity. Default: 0 minutes (does not expire).

For Designer Auth Tokens, these settings can be found on the Gateway General Security Settings page by navigating to Gateway > Config > Security > General. 

For Vision Client auth tokens, these settings can be found in the Designer by opening the Project Menu, selecting Project Properties and navigating to Vision > Login.

When redundancy is enabled, Vision Client auth tokens are synchronized from the Master to the Backup so that IdP-authenticated Vision Client sessions may be resumed seamlessly during failover by using an auth token.



In This Section ...


  • No labels