Single Sign-On

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

Sign-in options using registered OIDC providers

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

  • Continue with CORE - the partition selection is mandatory.
  • Continue with OIDCClosedOpenID 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 OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider and users authenticated by CORE, we will use the following terms:

In CORE, an SSO-userClosedUKC user that is authenticated by Single Sign-on provider is defined using the OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol claim or claims agreed by the CORE and the OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider. A claim is a snippet of personal information kept by OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol about each user. Once OIDCClosedOpenID 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 OIDCClosedOpenID 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

SSOClosedSingle Sign-On-users are managed by the CORE UI. An SSOClosedSingle 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 OIDCClosedOpenID 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 SSOClosedSingle 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 OIDCClosedOpenID 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

  1. Navigate to Partition SOClosedSecurity officer - UKC partition administrator role. ˃ Users ˃ Create.
  2. Follow the standard dialog up to the AuthenticationClosedProcess used to achieve sufficient confidence in the binding between the Entity and the presented Identity. method, then Click ▼.
  3. Select OpenID Connect.
  4. → The list of the registered OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol Providers appears.

  5. Select the provider that will authenticate the person whose SSO-aliasClosedUnique personal information that identifies an SSO-user you are entering.
  6. → An empty cell appears.

  7. Enter the person's OIDCClosedOpenID 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 SSOClosedSingle 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.

OIDC user

Edit SSO-user

Navigate to the Internal user that represents the SSO-userClosedUKC 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 SSOClosedSingle Sign-On-aliases or deleting the existing ones.

Note
Adding an SSO-aliasClosedUnique 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

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

Summary

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

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

SSO User as a Member in User Group

An SSOClosedSingle 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 OIDCClosedOpenID 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-userClosedUKC user that is authenticated by Single Sign-on provider members of the group.

Troubleshooting of SSO User Sign-in

We distinguish two cases:

Troubleshooting Single SSO-user

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

Troubleshooting OIDC Client

If the login attempts are declined for all SSOClosedSingle Sign-On-users of a particular OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol, the likely reason is an OIDCClosedOpenID 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 OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol. An error could occur during one of the following phases: