Noah ES can integrate with third-party authentication systems – for example, Microsoft Azure Active Directory, OpenID Connect, however this document is specifically for OpenID Connect integration.
OpenID Connect is an authentication and authorization protocol that enables SSO for web and mobile applications.
When adding a new Single Sign-on Configuration in the NoahES App Portal (Settings->Single Sign-on) by clicking the (+) plus symbol and choosing OpenID Connect - a number of fields for configuring Single Sign-On (SSO) with OpenID Connect must be filled in.
The specific values you enter for these fields depend on the OpenID Connect provider you are using, as they provide the necessary information for configuration. Be sure to consult the documentation provided by your OpenID Connect provider for precise details on what to enter in these fields.
The example values for the fields below are values as they might look for using OKTA as a third-party OpenID Connect identity provider. There are no ‘Example’ values for fields that isn’t required by OKTA.
Here follows a description of the fields and what kind of information that can be entered:
Name: Description: A user-friendly name for the OpenID Connect configuration. It's just a label for your reference (currently limited to 7 characters). Example: okta1
Client ID Override: Description: The client ID is a unique identifier for your application when it interacts with the OpenID Connect provider (e.g., an identity provider or IdP). Some systems allow you to override the default client ID for specific purposes. When integrating with a third-party service or identity provider, they may provide you with a specific Client ID to use for the integration. In such cases, you would override the default Client ID with the one provided by the third party.
When using OKTA as Identity Provider - then this value is the ClientID of the App registration that was created in OKTA to use for this connection. Example: 0oa5nnzacr0ajkYQV691
ACR: Description: The Authentication Context Reference (ACR) is an optional value that can be included in the authentication request used to specify a set of business rules that authentications are being requested to satisfy.
Such rules can often be satisfied by using several different specific authentication methods, either singly or in combination. Authentication Requests using this value request that the specified Authentication Context be used and that the resulting ID Token should contain an ACR claim saying which Authentication Context Class was satisfied.
Issuer: Description: The issuer is the URL of the OpenID Connect provider (Identity Provider). It's typically a well-defined URL where the provider publishes its metadata. It's also used to verify the authenticity of the OpenID Connect provider. This is the URL or GUID that identifies the Identity provider. Example:https://trial-7866800.okta.com
Metadata URL: Description: This is a URL provided by the OpenID Connect provider that contains metadata about the provider's configuration. It includes information such as endpoints, supported scopes, and more. Instead of manually configuring every detail, you can often enter this URL to automatically populate the settings. This URL often ends with "/.well-known/openid-configuration", which represents the identity provider's discovery document. Example: https://trial-7866800.okta.com/.well-known/openid-configuration
Logon URL: Description: This is the URL where the user will be redirected to log in when they access your application. It's typically provided by the OpenID Connect provider and is used in the authentication process. Example: Example: https://trial-7866800.okta.com/oauth2/v1/authorize
Logout URL: Description: This is the URL where the user will be redirected after logging out from your application. It's also provided by the OpenID Connect provider and is used to terminate the user's session. Example:https://trial-7866800.okta.com/oauth2/v1/logout
Signing Key: Description: The signing key is the public key used to verify the digital signatures on tokens issued by the OpenID Connect provider. It’s ensuring the integrity and authenticity of tokens. The key can be in the form of a URL or the actual public key.
If the value for the “Meta data URL” field has not been specified then at least one signing key must be provided as JSON. This example below only includes one key. { "keys": [{ "kty": "RSA", "use": "sig", "kid": "A8E67B3C86C53858DE0672CFA2BF144A48BA5136RS256", "e": "AQAB", "n": "q9Gf89dlUoRwMB7wafIvydrZuOwupzZvwLAXPJeBXy_UePtSeJdeUf9 oc_3npEOlIfqNZyJqGrNQy9ae88JLZ2uiSlKwwe2EXQG8Zu7pFcQKoiDnd_6kdsOsds Uuxe_Wx-TFB3ZVgnAetkZa3WJq1nkQKZ6JplvDBu8YrC_W4L8Lw-hd6defeenF0Imna Wx8mCtABIK4ndLiUnifDYhgp7jCg4Q_Vn69AZuidpxqVw5ygT-yLx5HbYeRsTwAumCB VfFpmS_nnOLyJKg3081v_ulTl_wqiAnBe7azNApxY5I2dItV6UEhVzzDf-t9cCqUOIV k31-bx5JjzR7FkLxG0Q", "alg": "RS256" }] }
!! Please observe that the ‘kty’ (Key Type) parameter only supports the ‘RSA’ value and the ‘use’ (public key use) parameter only supports the ‘sig’ value.
!! If ‘SigningKey’ is provided as JSON it must be manually updated when one of the keys expires.
