Identity Provider Authentication Strategy
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). Note that launching a project from an IdP-initiated SSO response is not currently supported.
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.
​
If your browser is not supported, you will get an error message.
Identity Provider Authentication Workflow​
The following diagram illustrates how IdP authentication works.
User make a login attempt to the Gateway, Perspective, the Designer, or a Vision Client.
Ignition sees that IdP authentication is required.
Ignition redirects the User to Identity Provider for authentication of their credentials.
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).
User Responds: The user correctly responds to the security challenge.
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.
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​
​
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.