Ignition 8.1
Ignition 7.9
Ignition 7.8
Sepasoft - MES Modules
Cirrus Link - MQTT Modules
Inductive University
Ignition Demo Project
Knowledge Base Articles
Forum
IA Support
SDK Documentation
SDK Examples
You're currently browsing the Ignition 8.0 docs. Click here to view the latest docs.
Before configuring an Identity Provider on the Ignition Gateway, it must first be registered as an Identity Provider Client. Your Identity Provider will have a workflow to register, and it will most likely request something called a return URL or redirect URI. The paths provided utilize your Gateway's address/hostname, and they change depending on the type of provider.
The same redirect URI is used for login and logout.
OpenID Connect Providers (OP):
http://yourGatewayAddress:Port/data/federate/callback/oidc
SAML Providers:
http://yourGatewayAddress:Port/data/federate/callback/saml
You should always use the secure SSL versions of those redirect URIs (https) in production environment. To do this you must enable SSL in Ignition and install a valid certificate. This is the best practice for maintaining a secure integration with third party Identity Providers.
Although there are several types, the general workflow for creating an Identity Provider is the same.
All Identity Provider types share the following properties:
| Property Name | Description | Required? |
|---|---|---|
| Provider Name | The name of the adapter. Adapter names must be unique, so no two adapters on the same Gateway may have the same name. The following feature is new in Ignition version 8.0.6
Click here to check out the other new features As of release 8.0.6, the naming conventions for IdPs are as follows:
| Yes |
| Provider Description | A description of the provider. | No |
| Provider Type | The type of Identity Provider. The value for this field comes from the previous screen. It cannot be changed here. | Yes |
The Ignition Identity Provider has the following properties:
| Property Name | Description | Required? |
|---|---|---|
| User Source | The User Source for this IdP. In order to properly authenticate users, the Ignition Identity Provider must be able to query the list of users from the underlying user source profile. Ensure that your Active Directory, Database, and Hybrid user source profiles are configured accordingly to allow for this. | Yes |
Authentication Methods |
The following feature is new in Ignition version 8.0.5
Click here to check out the other new features | Yes |
Badge Secret |
The following feature is new in Ignition version 8.0.5
Click here to check out the other new features | Yes |
The following attributes are available in the Ignition IdP.
| Attribute | Type | Description | Example |
|---|---|---|---|
| auth_time | Date |
The following feature is new in Ignition version 8.0.14
Click here to check out the other new features Represents the time the user last authenticated. | // Check if it has been within 15 minutes since the last
// authentication attempt
dateDiff({idp-attributes:auth_time}, now(), "minutes") <= 15
|
| challenged | Boolean |
The following feature is new in Ignition version 8.0.14
Click here to check out the other new features Signifies if the user provided credentials at the last login. If true, then the user was asked to re-validate their credentials the last time they attempted to login. If false, then they were not challenged to re-validate their credentials during the last login attempt. This can happen when a login request was made after a user was already authenticated. For example, if a user was already authenticated in a Perspective Session, and a separate call to system.perspective.login function was made with the forceAuth parameter set to false, meaning the user did not provide credentials during the last authentication challenge. | // Returns True or False, depending on whether or not the user
// provided credentials at the last login.
{idp-attributes:challenged}
|
OpenID Connect Providers (OP) properties are listed in the following tables. The values on many of these properties may require you to refer to information from your third-party IdP.
This method is preferred because of its ease-of-use and accuracy. After importing, you will only need to add your client ID and secret manually. (However you can revise the imported data if needed as well.)
| Property Name | Description |
|---|---|
| Import from URL | URL to the OpenID Provider Configuration document. Typically, if the issuer is "https://example.org/foo" then the metadata URL would be "https://example.org/foo/.well-known/openid-configuration" |
| Import From File | File must be a JSON document with the properties described in section 3 (OpenID Provider Metadata) of the OpenID Connect Discovery 1.0 specification. |
Most OpenID Providers will require registering Ignition as a client. After the registration process is complete, the provider will generate a client ID and secret for Ignition, which is required below. This gives Ignition the ability to communicate securely with the provider. Most providers will also require a set of redirect URIs. An example redirect URI would look like: http://hostname:port/data/federate/callback/oidc
| Property Name | Description | Required? |
|---|---|---|
Client ID | The client identifier registered within the identity provider. This value is provided the Identity Provider. | Yes |
| Client Secret | The client secret registered within the identity provider. This value is provided by the Identity Provider. | Yes |
| Authorization URL | URL of the OP's OAuth 2.0 Authorization Endpoint. | Yes |
| Token URL | URL of the OP's OAuth 2.0 Token Endpoint. | Yes |
| Logout URL | Optional URL at the OP to which an RP can perform a redirect to request that the end user be logged out at the OP. | No |
| JSON Web Keys URL | URL of the OP's JSON Web Key Set document. | No |
| Use Json Web Keys URI | If checked, then identity provider public keys will be automatically downloaded from given JSON Web Keys URL. New keys will be automatically fetched when the identity provider generates new keys. If unchecked, then the static set of JSON Web Keys (configured below) are used, so when the identity provider rotates keys, they must be manually added to this configuration. | No |
| User Info URL |
The following feature is new in Ignition version 8.0.16
Click here to check out the other new features Optional URL to retrieve UserInfo claims from the provider. Resulting claims are typically determined by the scopes listed under the Scope setting. | No |
| Issuer | Entity that issues a set of claims. | Yes |
| Supported ID Token Signing Algorithm Values | A list of the JSON Web Signature (JWS) signing algorithms supported by the OP for the ID Token to encode the claims in a JWT. | Yes |
| Scope | A list of scopes which will be sent for each auth request to the OP. Commonly used scopes would be email and profile but check your Identity Provider's documentation for more information. | No |
| JSON Web Key Config | A list of signing key(s) the RP uses to validate signatures from the OP. | No |
| Property Name | Description | Required? |
|---|---|---|
| Key Type | The cryptographic algorithm family used with the key. Options are EC, RSA or oct. | Yes |
| Public Key Use | The intended use of the public key. Options are sig or eng. | No |
| Key Operations | The operation(s) for which the key is intended to be used. | No |
| Algorithm | The algorithm intended for use with the key. | Yes |
| Key ID | Used to match a specific key. | No |
| X.509 URL | A URI that refers to a resource for an X.509 public key certificate or certificate chain. The identified resource MUST provide a representation of the certificate or certificate chain that conforms to RFC 5280 in PEM-encoded form, with each certificate delimited as specified in Section 6.1 of RFC 4945. | No |
| X.509 Certificate Chain | The "x5c" (X.509 certificate chain) parameter contains a chain of one or more PKIX certificates. Each entry must be a base64-encoded (Section 4 of RFC4648 -- not base64url-encoded) DER PKIX certificate value. | No |
| X.509 Certificate SHA-1 Thumbprint | A base64url-encoded SHA-1 thumbprint (a.k.a. digest) of the DER encoding of an X.509 certificate. | No |
| X.509 Certificate SHA-256 Thumbprint | A base64url-encoded SHA-256 thumbprint (a.k.a. digest) of the DER encoding of an X.509 certificate. | No |
There are some additional properties, that depend on which Key Type is selected.
| Property Name | Description | Required? |
|---|---|---|
| crv (Curve) | The cryptographic curve used with the key. | Yes |
| x (X Coordinate) | The x coordinate for the Elliptic Curve point represented as the base64url encoding of the octet string representation of the coordinate. | Yes |
| y (Y Coordinate) | The y coordinate for the Elliptic Curve point represented as the base64url encoding of the octet string representation of the coordinate. | No |
| d (ECC Private Key) | The Elliptic Curve private key value represented as the base64url encoding of the octet string representation of the private key value. | No |
| Property Name | Description | Required? |
|---|---|---|
| n (Modulus) | The modulus value for the RSA public key represented as a Base64urlUInt-encoded value. | Yes |
| e (Exponent) | The exponent value for the RSA public key represented as a Base64urlUInt-encoded value. | Yes |
| d (Private Exponent) | The private exponent value for the RSA public key represented as a Base64urlUInt-encoded value. | No |
| p (First Prime Factor) | The first prime factor represented as a Base64urlUInt-encoded value. | No |
| q (Second Prime Factor) | The second prime factor represented as a Base64urlUInt-encoded value. | No |
| dp (First Factor CRT Exponent) | The Chinese Remainder Theorem (CRT) exponent of the first factor represented as a Base64urlUInt-encoded value. | No |
| dq (Second Factor CRT Exponent) | The CRT exponent of the second factor represented as a Base64urlUInt-encoded value. | No |
| qi (First CRT Coefficient) | The CRT coefficient of the second factor represented as a Base64urlUInt-encoded value. | No |
| oth (Other Primes Info) | Information about any third and subsequent primes, should the exist. Each new Prime added will provide users with new Prime Factor, Factor CRT Exponent, and Factor CRT Coefficient properties, all of which are required. | No |
| Property Name | Description | Required? |
|---|---|---|
| k (Key Value) | The value of the symmetric (or other single-values) key represented as the base64url encoding of the octet sequence containing the key value. | Yes |
The properties for Security Assertion Markup Language (SAML) are listed in the following tables. The values on many of these properties may require you to refer to information from your third-party IdP.
This method is preferred because of its ease-of-use and accuracy. After importing, you will only need to add your client ID and secret manually. (However you can revise the imported data if needed as well.)
| Property Name | Description |
|---|---|
| Import from URL | URL to the SAML Identity Provider Metadata document. |
| Import From File | File must be an XML document which conforms to the SAML 2.0 metadata schema described in saml-metadata-2.0-os. |
The SAML Service Provider (SP) metadata for an Ignition Gateway may be accessed at the following URL: http://<ipaddress>:<port>/data/saml/metadata/sp.
The Assertion Consumer Service (ACS) URL for this Ignition Gateway is: http://<ipaddress>:<port>/data/federate/callback/saml
Both of these addresses assume you know the IP Address and port of your Ignition install. For example, if you are on the computer Ignition is installed on, you could use: http://localhost:8088/data/saml/metadata/sp for the SP metadata.
| Property Name | Description | Required? |
|---|---|---|
Entity ID | The Identity Provider's Entity ID. | Yes |
| Assertion Consumer Service (ACS) Binding | The expected binding used by the Identity Provider when interacting with Ignition's Assertion Consumer Service. | Yes |
| Name ID Format | The expected name ID format for subjects of assertions resulting from Authn Requests. Options are UNSPECIFIED, EMAIL_ADDRESS, X509_SUBJECT_NAME, WINDOWS_DOMAIN_QUALIFIED_NAME, KERBEROS_PRINCIPAL_NAME, ENTITY_IDENTIFIER, PERSISTENT_IDENTIFIER, TRANSIENT_IDENTIFIER. | Yes |
| Single Sign-On (SSO) Service URL | The Identity Provider's Single Sign-On (SSO) Service URL. | Yes |
| Single Sign-On (SSO) Service Binding * | The binding Ignition will use for sending Authn Requests to the Identity Provider's Single Sign-On (SSO) Service. | Yes |
| Force Authn | Check this box to force complying Identity Providers to authenticate the user each time instead of relying on a previous security context. See section 3.4.1 of saml-core-2.0-os for more details. | Yes |
| Validate Response Signatures | Check this box to validate the signature of the response from the Identity Provider. | Yes |
| Validate Assertion Signature | Check this box if it is expected that assertions will be signed. Ignition will validate the signatures of each assertion. | Yes |
| Signature Verifying Keys | A list of signing key(s) that Ignition uses to validate signatures from the IdP. | Yes |
| Signature Verifying Certificates | A base64-encoded DER PKIX certificate value. | No |
| Property Name | Description | Required? |
|---|---|---|
| Key Algorithm | The algorithm identifier for this signature verifying key. Options are DSA, RSA, or EC. | Yes |
| Key Value | A base64-encoded DER key value. | Yes |
The OpenID Connect 1.0 Example page will show you how to configure an external IdP that used OpenID Connect 1.0 with your Ignition system.
Go to Troubleshooting Identity Providers for helpful examples to help you diagnose and troubleshoot issues with configuring IdPs.
Refer to SAML Example page for how to configure an Identity Provider that is using the SAML protocol.
