Managing OIDC Providers

CORE implements the OpenID Connect Client specification.

Shared Settings

The following settings are shared by the CORE (OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol client) and its OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider (OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol server):

The following table summarizes the shared setting ownership:

Setting Value owned by Delivered to
OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol URL OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider CORE
OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol Client Id OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider CORE
OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol Client Secret OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider CORE
CORE Reroute URL CORE OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider
Claims and Scopes Claims and Scopes are mutually agreed upon between the OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol and UCLClosedUnbound Command Language

Claims and Scopes in a Nutshell

The Claims setting defines the type of personal information that:

For example, an email claim specifies the person's email address as the expected type of personal information.

In CORE, the OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol claims are tightly related to SSOClosedSingle Sign-On-aliases associated with the CORE username object (see Create an SSO-user). For example, suppose the partition SOClosedSecurity officer - UKC partition administrator role. uses a person's email address to specify its SSO-aliasClosedUnique personal information that identifies an SSO-user. In this case, email is the type of personal information that the CORE expects to receive from the OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol.

Note
Single Sign-On of a CORE user depends on the precise specification of the personal information that CORE expects to receive from OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol.

Yet, an "email" without any annotation may indicate your work or personal email. The same applies to the claim identified by "name". It may refer to your name, name of your pet, mother's maiden name, name of your primary school.

To mitigate a possible misinterpretation of the required claim, any claim must be prefixed with its "scope". Similar to claims, the name used to identify a scope and all its claims must be agreed upon between the OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol and CORE . For example, an "email" claim must be listed in one of the scopes agreed upon between CORE and OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol.

The standard OpenID scopes and claims are defined here and are listed in the following table for quick reference. Note, for example, that the "email" scope contains two claims, one of which may be used to enforce email verification by OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol.

Scope Claims
openid

See OpenID Core Spec - Token.
Among its mandatory claims are the sub(ject) claim that uniquely identifies the person in the provider's database and the iss(uer) claim that uniquely identifies the OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider. The iss-sub pair is the permanent identification of a person.

email email and email_verified claims.
The default choice for the person's alias in the CORE.
profile namefamily_namegiven_namemiddle_namenicknamepicture, and updated_at.

Note
By default, CORE expects the person's email address as its SSO-aliasClosedUnique personal information that identifies an SSO-user. Therefore, both the "email" scope and the "email" claim must be agreed upon between CORE and OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol as the type of personal information to be returned to CORE.

OIDC Provider Management in CORE

To manage OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol providers, log in to the UI using the Root SOClosedSecurity officer - UKC partition administrator role. credentials and navigate to Root SOClosedSecurity officer - UKC partition administrator role. ˃ Configuration ˃ OpenID.

→ A list of the configured providers (if any) appears.

Add the New OIDC Provider

  1. Navigate to Root SOClosedSecurity officer - UKC partition administrator role. ˃ Configuration ˃ OpenID > Add.
  2. → A new OpenID Connect provider dialog appears.

  3. Click Provider template.
  4. → A list of providers appears.

    Select the provider. If the required provider is listed, choose it. Otherwise, select Custom provider.

  5. Enter Name and Description. The name cannot be changed later.
  6. Enter the URL of the provider's endpoint that is used for the authentication.
  7. Note
    The URL is validated once you leave the field. If it does not provide the expected response, it is flagged as an error.

  8. Enter the CORE credentials that the OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider assigned:
    • Client ID - CORE service account ID assigned to it by the provider.
    • Client Secret - secret associated with the ID.

    For example, see Registering CORE as an OIDC Client.

  9. Enter the personal information specification that CORE expects to receive from the provider.
    • Required scopes and Claims - see the description in Claims and Scopes in a Nutshell. As needed, add custom claims and scopes that were agreed upon with the provider.

Other Commands

CORE Settings in OIDC Provider

The OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider needs the following details about the client:

Integration with the Microsoft Identity Platform

In this example, we register a CORE system with the Microsoft Identity Platform v2 that serves your organization.

Note
Prerequisite: You are an Admin of your organization's Microsoft cloud services tenant or, at least, External ID user flow administrator.

The following Azure icons are referred to in this example:

Relevant Azure icons

Registering CORE as an OIDC Client

Select the Tenant whose subscribers need access to CORE:

  1. Sign in to the Azure portal.
  2. Click the filter icon that represents Directory + subscription in the top panel.
  3. → A list of directories appears.

  4. Select the required directory and copy its tenant name <tenant name>.onmicrosoft.com or the tenant ID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx that shows next to the name.
  5. Note
    This is the OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol URL that you program in Step#4 of Add the New OIDC Provider ("STS" stands for "Secure Token Service"):
    https://sts.windows.net/<tenant name>.onmicrosoft.com
    or
    https://sts.windows.net/<xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx>

Register the tenant as the Azure AD client.

  1. Search for and select the Azure Active Directory.
  2. Under Manage, select App registrations > New registration.
    Register an application dialog appears.
    1. Enter Name for the CORE application. For example, CORE.
    2. Select Supported account types. For example, Accounts in this organizational directory only (Single-tenant).
    3. Skip Redirect URI - it is filled in Configure the App Type and the Token Type.
    4. Click Register.
    5. → App registration's Overview appears. It presents the CORE client ID (Application (client) ID)

      Azure App Registration Dialog

Configuring CORE as an OIDC Client

Configure the App Type and the Token Type

  1. Go to App registrations in the Azure portal and select your application ("CORE ").
  2. In the left pane, under Manage, select Platform Configurations.
  3. Platform Configurations dialog appears.

  4. Click Add platform.
  5. → A list of possible application types appears (such as Web, Android, and Single-page).

  6. Click Web.
  7. Configure Web dialog appears.

    1. In Redirect URIs enter all possible URI that your organization may use to sign in the CORE .
    2. Note
      The URI is case-sensitive.

    3. In Select the tokens you would like to be issued by the authorization endpoint, check ID tokens (used for implicit and hybrid flows).
    4. Click Configure.
    5. → The summary appears for your review and possible changes.

Generate the Client ID and Secret used by CORE

  1. Go to App registrations in the Azure portal and select your application ("CORE ").
  2. In the left pane, under Manage, select Certificates and Secrets.
  3. Certificates and Secrets dialog appears.

  4. Under Client Secrets, click New client secret.
  5. → Client ID and Client Secret are generated.

    Note
    These are the Client ID and Secret that you program in Step#5 of Add the New OIDC Provider. The secret permanently disappears once you leave the page.

Set the Claims

  1. Go to App registrations in the Azure portal and select your application ("CORE ").
  2. In the left pane, under Manage, select Token configuration.
  3. Token configuration dialog appears.

  4. Click Add optional claim.
  5. → A list of possible token types appears (such as ID, Access, and SAML).

  6. Click ID.
  7. → A list of possible claims appears.

  8. Check email and click Add.
  9. Turn on the Microsoft Graph email permission checkbox appears.

  10. Check the permission and click Add.