Configure NoahES for OpenID Connect single sign-on

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.

We provide an example using Okta:

Setting Up Noah ES within the Identity Provider (Okta)

In Okta, create a new “App Integration” by selecting the OIDC sign-in method and Application Type = Web Application.

• specify a "Sign-in"- and "Sign-out"- redirect URI at the third-party OpenID Connect providers configuration page.
  The URI depend upon the NoahES data center where the tenant (account) is hosted. See Points 1 and 2 in the diagram to the right

Diagram 1

Diagram 2

Diagrams 3-4

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.

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

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.

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. Note: make sure to not include a '/' at the end of the URL address. For example ……okat.com/ may cause the integration to fail.
   Example: See Point 3 in Diagram 5

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 ends with "/.well-known/openid-configuration", which represents the identity provider's discovery document.
   Example:see Point 4 in Diagram 5

5. 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: See Point 5 in Diagram 5

6. 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: See Point 6 in Diagram 5

Diagram 5