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 OIDC
OpenID Connect is identity layer on top of the OAuth 2.0 protocol provider (OIDC
OpenID Connect is identity layer on top of the OAuth 2.0 protocol server):
- OIDC
OpenID Connect is identity layer on top of the OAuth 2.0 protocol URL - URL of the OIDC
OpenID Connect is identity layer on top of the OAuth 2.0 protocol provider.
- OIDC
OpenID Connect is identity layer on top of the OAuth 2.0 protocol Client Id - an ID assigned to the CORE application by OIDC
OpenID Connect is identity layer on top of the OAuth 2.0 protocol.
- OIDC
OpenID Connect is identity layer on top of the OAuth 2.0 protocol Client Secret - a secret assigned to the CORE application by OIDC
OpenID Connect is identity layer on top of the OAuth 2.0 protocol.
- CORE Reroute URL - one of the CORE URLs to be used by OIDC
OpenID 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 OIDC
OpenID 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 |
---|---|---|
OIDC![]() |
OIDC![]() |
CORE |
OIDC![]() |
OIDC![]() |
CORE |
OIDC![]() |
OIDC![]() |
CORE |
CORE Reroute URL | CORE | OIDC![]() |
Claims and Scopes | Claims and Scopes are mutually agreed upon between the OIDC![]() ![]() |
Claims and Scopes in a Nutshell
The Claims setting defines the type of personal information that:
- CORE expects to receive from OIDC
OpenID Connect is identity layer on top of the OAuth 2.0 protocol.
- The OIDC
OpenID 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 SSO
Single Sign-On-aliases associated with the CORE username object (see Create an SSO-user). For example, suppose the partition SO
Security officer - UKC partition administrator role. uses a person's email address to specify its SSO-alias
Unique 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 OIDC
OpenID 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 OIDC
OpenID 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. |
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 OIDC
OpenID 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 SO
Security officer - UKC partition administrator role. credentials and navigate to Root SO
Security officer - UKC partition administrator role. ˃ Configuration ˃ OpenID.
→ A list of the configured providers (if any) appears.
Add the New OIDC Provider
- Navigate to Root SO
Security officer - UKC partition administrator role. ˃ Configuration ˃ OpenID > Add.
- Click Provider template.
- Enter Name and Description. The name cannot be changed later.
- Enter the URL of the provider's endpoint that is used for the authentication.
- Enter the CORE credentials that the OIDC
OpenID 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.
- 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.
→ A new OpenID Connect provider dialog appears.
→ A list of providers appears.
Select the provider. If the required provider is listed, choose it. Otherwise, select Custom provider.
Note
The URL is validated once you leave the field. If it does not provide the expected response, it is flagged as an error.
Other Commands
- Edit - allows modifying all attributes of the selected OIDC
OpenID 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 SSO-user
UKC user that is authenticated by Single Sign-on provider personal info item(s) (claims) that should be provided to CORE.
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-user
UKC 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 OIDC
OpenID Connect is identity layer on top of the OAuth 2.0 protocol. OIDC
OpenID Connect is identity layer on top of the OAuth 2.0 protocol makes sure that the request is coming from the approved source.
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:
- Sign in to the Azure portal.
- Click the filter icon
that represents Directory + subscription in the top panel.
- 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.
→ A list of directories appears.
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
orhttps://sts.windows.net/<
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
>
Register the tenant as the Azure AD client.
- Search for and select the Azure Active Directory.
-
Under Manage, select App registrations > New registration.
→ Register an application dialog appears.- Enter Name for the CORE application. For example, CORE.
- Select Supported account types. For example, Accounts in this organizational directory only (Single-tenant).
- Skip Redirect URI - it is filled in Configure the App Type and the Token Type.
- 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
- Go to App registrations in the Azure portal and select your application ("CORE ").
- In the left pane, under Manage, select Platform Configurations.
- Click Add platform.
- Click Web.
- In Redirect URIs enter all possible URI that your organization may use to sign in the CORE .
- In Select the tokens you would like to be issued by the authorization endpoint, check ID tokens (used for implicit and hybrid flows).
- Click Configure.
→ Platform Configurations dialog appears.
→ A list of possible application types appears (such as Web, Android, and Single-page).
→ Configure Web dialog appears.
Note
The URI is case-sensitive.
→ The summary appears for your review and possible changes.
Generate the Client ID and Secret used by CORE
- Go to App registrations in the Azure portal and select your application ("CORE ").
- In the left pane, under Manage, select Certificates and Secrets.
- Under Client Secrets, click New client secret.
→ Certificates and Secrets dialog appears.
→ 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
- Go to App registrations in the Azure portal and select your application ("CORE ").
- In the left pane, under Manage, select Token configuration.
- Click Add optional claim.
- Click ID.
- Check email and click Add.
- Check the permission and click Add.
→ Token configuration dialog appears.
→ A list of possible token types appears (such as ID, Access, and SAML).
→ A list of possible claims appears.
→ Turn on the Microsoft Graph email permission checkbox appears.