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 (SSO
Single Sign-On) authentication for the CORE partition users. The CORE UI login page presents the standard login option and a list of the registered SSO
Single 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 OIDC
OpenID 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-user
UKC 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 OIDC
OpenID Connect is identity layer on top of the OAuth 2.0 protocol claim(s) agreed by the CORE and the OIDC
OpenID 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 OIDC
OpenID 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 SSO
Single 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 OIDC
OpenID 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 OIDC
OpenID 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 SO
Security officer - UKC partition administrator role. ˃ Users ˃ Create.
- Follow the standard dialog up to the Authentication
Process used to achieve sufficient confidence in the binding between the Entity and the presented Identity. method, then Click ▼.
- Select OpenID Connect.
- Select the provider that will authenticate the person whose SSO-alias
Unique personal information that identifies an SSO-user you are entering.
- Enter the person's OIDC
OpenID Connect is identity layer on top of the OAuth 2.0 protocol claim.
→ The list of the registered OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol Providers appears.
→ An empty cell appears.
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 Authentication
Process used to achieve sufficient confidence in the binding between the Entity and the presented Identity. type: OIDC
OpenID Connect is identity layer on top of the OAuth 2.0 protocol. To find such a user's SSO-alias
Unique personal information that identifies an SSO-user, use the Show Info command.
Summary
- 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-user
UKC 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 OIDC
OpenID 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 OIDC
OpenID 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 SSO
Single 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 OIDC
OpenID 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-user
UKC 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-user
UKC user that is authenticated by Single Sign-on provider. See SSO User as a Member in User Group.
- Sign-in is declined for all SSO
Single 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 SSO
Single 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 OIDC
OpenID 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 SSO
Single 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 OIDC
OpenID 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 OIDC
OpenID Connect is identity layer on top of the OAuth 2.0 protocol, the likely reason is an OIDC
OpenID 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 OIDC
OpenID Connect is identity layer on top of the OAuth 2.0 protocol. An error could occur during one of the following phases:
- Authentication
Process used to achieve sufficient confidence in the binding between the Entity and the presented Identity. request phase. See Authentication Request Validation and Authentication Response Validation.
- ID Token
JSON Web Token (JWT) that contains Claims about the Authentication event. request phase. See Token Request Validation and Token Response Validation.