Single Sign-On

CORE SOs may leverage CORE integration with the OpenID Connect (OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol) providers enabling the Single Sign-On (SSOSingle Sign-On) authentication for the CORE partition users. The CORE UI login page presents the standard login option and a list of the registered SSOSingle Sign-On providers. To log in, select the personal authentication option, as needed, specify the required partition, and proceed as directed.

The selection of the required partition depends on your login method:

Continue with CORE - the partition selection is mandatory.
Continue with OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol - allows to bypass the selection:
- If a partition is specified - a user will attempt to login to the specified partition and stay there.
- If a partition is not specified - a user will be signed into one of the partitions where it is registered. Using the partition's UI, it may roam among its registered partitions.

To differentiate between users authenticated by the OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider and users authenticated by CORE, we will use the following terms:

SSO-userUKC user that is authenticated by Single Sign-on provider - indicates that the OpenID Connect provider authenticates the user.
Internal user - indicates that CORE authenticates the user.

In CORE, an SSO-userUKC user that is authenticated by Single Sign-on provider is defined using the OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol claim(s) agreed by the CORE and the OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider. A claim is a snippet of personal information kept by OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol about each user. Once OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol Provider authenticates a user, it forwards to the EP personal information claims that
- were agreed between OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol and CORE.
- were consented by the user for sharing with CORE.
For example, a claim may be the person's email address.

The received claim is matched with the patterns stored in the specified partition or all partitions. This process results in a set of partitions where the user can operate.

SSO User

SSOSingle Sign-On-users are managed by the CORE UI. An SSOSingle Sign-On user may be defined in a CORE partition using the following methods:

An alias of an Internal user. In such a case, the expected OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol claim is added to the alias list of an Internal user.
An expression that includes the claim about the user. Such an expression is specified in a User Group of the partition. As needed, it may be defined in several user groups.

SSO-user as Alias of Internal User

An SSOSingle Sign-On user may be defined as an alias of an Internal user by specifying its unique personal info claim in the user's settings. In such a case, the OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol user's role and other properties as defined for the Internal user.

Create an SSO-user

Navigate to Partition SOSecurity officer - UKC partition administrator role. ˃ Users ˃ Create.
Follow the standard dialog up to the AuthenticationProcess used to achieve sufficient confidence in the binding between the Entity and the presented Identity. method, then Click ▼.
Select OpenID Connect.

→ The list of the registered OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol Providers appears.

Select the provider that will authenticate the person whose SSO-aliasUnique personal information that identifies an SSO-user you are entering.

→ An empty cell appears.

Enter the person's OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol claim.

Show an SSO-user

The show info command of an Internal user presents aliases of all SSOSingle Sign-On-users registered under the specified CORE username. The following image shows a group of four people that have the same role in the partition.

Edit SSO-user

Navigate to the Internal user that represents the SSO-userUKC user that is authenticated by Single Sign-on provider.

Edit. Besides modifying the CORE attributes, such as the user's role or the alias itself, this function allows adding new SSOSingle Sign-On-aliases or deleting the existing ones.

Note
Adding an SSO-aliasUnique personal information that identifies an SSO-user of a new person allows creating a group of people that share the same role.

List SSO-users

SSOSingle Sign-On-users are listed with the rest of the partition usernames. In the list, they are identified by the AuthenticationProcess used to achieve sufficient confidence in the binding between the Entity and the presented Identity. type: OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol. To find such a user's SSO-aliasUnique personal information that identifies an SSO-user, use the Show Info command.

Summary

AuthenticationProcess used to achieve sufficient confidence in the binding between the Entity and the presented Identity. type:

The authentication type of a CORE username is assigned upon the user's creation. It cannot be changed.

Note
The default usernames SOSecurity officer - UKC partition administrator role. and USER are authenticated using their CORE credentials

SSO-aliasUnique personal information that identifies an SSO-user:

In CORE, an SSO-userUKC user that is authenticated by Single Sign-on provider is identified by its unique personal information item. It must be the exact replica of the personal info that OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol provides.
The type of unique personal info is agreed upon between the CORE and the OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider. See Claims and Scopes in a Nutshell.
You may group aliases of many SSOSingle Sign-On-users under the same CORE username.

SSO User as a Member in User Group

An SSOSingle Sign-On user may be defined as a member of a User Group in the partition. See Add User Group. In such a case, the OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol claim regarding the user must match the regular expression that specifies the eligible SSO-userUKC user that is authenticated by Single Sign-on provider members of the group.

Troubleshooting of SSO User Sign-in

We distinguish two cases:

Sign-in is declined for specific SSO-userUKC user that is authenticated by Single Sign-on provider. See SSO User as a Member in User Group.
Sign-in is declined for all SSOSingle Sign-On-users. See Troubleshooting OIDC Client.

Troubleshooting Single SSO-user

The troubleshooting of this case depends on the sign-in phase that resulted in the error:

Sign-in was declined before authentication by the SSOSingle Sign-On provider.

Ask the person what <EP> they used in https://<EP>/login. For security reasons, they must use one of the <EP> values configured in their OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider. See CORE Settings in OIDC Provider. Using any other way to browse the UI sign-in page will not let them into the OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol authentication process. This error appears as the redirect_uri error.

Sign-in was declined by the SSOSingle Sign-On provider.

See the organization's OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol administrator.

Sign-in was declined by CORE

This type of decline appears to the user as the standard CORE rejection of the provided credentials.
A likely reason is that the person's SSO-aliasUnique personal information that identifies an SSO-user setting in the CORE no longer matches their personal information ("claim") provided by the OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol. To verify this assumption, enable EKM Trace Logs and examine the personal information as it appears in the trace log. If there is such a record in the log file, your assumption is correct. Modify the person's alias in the corresponding CORE username.

Troubleshooting OIDC Client

If the login attempts are declined for all SSOSingle Sign-On-users of a particular OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol, the likely reason is an OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol Auth Code Flow protocol error. This protocol includes different network legs involving the user's browser, CORE, and OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol. An error could occur during one of the following phases: