Managing OIDC Providers

CORE implements the OpenID Connect Client specification.

Shared Settings

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

• OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol URL - URL of the OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider.
• OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol Client Id - an ID assigned to the CORE application by OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol.
• OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol Client Secret - a secret assigned to the CORE application by OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol.
• CORE Reroute URL - one of the CORE URLs to be used by OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol.
• Claims and Scopes - see Claims and Scopes in a Nutshell. By default, the following claims and scopes settings must be defined in CORE and OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol:
  • claims: email
  • scopes: email

The following table summarizes the shared setting ownership:

Setting	Value owned by	Delivered to
OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol URL	OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider	CORE
OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol Client Id	OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider	CORE
OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol Client Secret	OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider	CORE
CORE Reroute URL	CORE	OIDCOpenID 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 OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol and UCLUnbound Command Language

Claims and Scopes in a Nutshell

The Claims setting defines the type of personal information that:

• CORE expects to receive from OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol.
• The OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol should ask the person's permission to disclose to CORE.

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

In CORE, the OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol claims are tightly related to SSOSingle Sign-On-aliases associated with the CORE username object (see Create an SSO-user). For example, suppose the partition SOSecurity officer - UKC partition administrator role. uses a person's email address to specify its SSO-aliasUnique 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 OIDCOpenID 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 OIDCOpenID 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 OIDCOpenID 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 OIDCOpenID 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 OIDCOpenID 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 OIDCOpenID 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	name, family_name, given_name, middle_name, nickname, picture, and updated_at.

Note
By default, CORE expects the person's email address as its SSO-aliasUnique personal information that identifies an SSO-user. Therefore, both the "email" scope and the "email" claim must be agreed upon between CORE and OIDCOpenID 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 OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol providers, log in to the UI using the Root SOSecurity officer - UKC partition administrator role. credentials and navigate to Root SOSecurity 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 SOSecurity officer - UKC partition administrator role. ˃ Configuration ˃ OpenID > Add.

→ A new OpenID Connect provider dialog appears.

2. Click Provider template.

→ A list of providers appears.

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

3. Enter Name and Description. The name cannot be changed later.
4. Enter the URL of the provider's endpoint that is used for the authentication.

Note
The URL is validated once you leave the field. If it does not provide the expected response, it is flagged as an error.

5. Enter the CORE credentials that the OIDCOpenID 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.

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

• Edit - allows modifying all attributes of the selected OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider except its name.
• Delete - allows deleting the provider if none of the CORE users specify it as their identity authenticator.

CORE Settings in OIDC Provider

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

• URL(s) of the CORE endpoint(s). Also known as redirect_uri.

The CORE endpoint is https://<EP>/login. The <EP> may be provided in different forms.

Note
An OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol configuration accepts multiple redirect_uri. For example, you can specify <EP1>/login and <EP2>/login to allow SSO-userUKC user that is authenticated by Single Sign-on provider login when the <EP1> server is out of service.

Note
To be accepted to the OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol authentication, a person must browse to the CORE login page using one of the https://<EP>/login options from the list configured in the OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol. OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol makes sure that the request is coming from the approved source.


• The SSO-userUKC user that is authenticated by Single Sign-on provider personal info item(s) (claims) that should be provided to CORE.

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:

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.

→ A list of directories appears.

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

Note
This is the OIDCOpenID 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.
   → App registration's Overview appears. It presents the CORE client ID (Application (client) ID)

   

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.

→ Platform Configurations dialog appears.

3. Click Add platform.

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

4. Click Web.

→ Configure Web dialog appears.

1. In Redirect URIs enter all possible URI that your organization may use to sign in the CORE .

Note
The URI is case-sensitive.

2. In Select the tokens you would like to be issued by the authorization endpoint, check ID tokens (used for implicit and hybrid flows).
3. Click Configure.

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

→ Certificates and Secrets dialog appears.

3. Under Client Secrets, click New client secret.

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

→ Token configuration dialog appears.

3. Click Add optional claim.

→ A list of possible token types appears (such as ID, Access, and SAML).

4. Click ID.

→ A list of possible claims appears.

5. Check email and click Add.

→ Turn on the Microsoft Graph email permission checkbox appears.

6. Check the permission and click Add.