Page Comparison

Setting Up Single Sign-on within the Noah ES Portal

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: (See Diagram 5 for examples)

1. 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
   

2. 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
   

3. 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.
   

See point C in Diagram 2

3. 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:

3. See Point 3

4. 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

3. ends with "/

3. well-known/openid-configuration", which represents the identity provider's discovery document.
   Example:

3. see Point 4

   Code Block
   /.well-known/openid-configuration

4. 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. This URL ends with “/oauth2/v1/authorize
   Example:

3. See Point 5

   Code Block
   /oauth2/v1/authorize

4. 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. This URL ends with “/oauth2/v1/logout”
   Example: https://trial-7866800.okta.com/oauth2/v1/logout

3. Code Block
   /oauth2/v1/logout