CORE Users

CORE user represents a person or an application that manages or uses elements of the CORE system.

Default Users

The first CORE user is the security officer (SOClosedSecurity officer - UKC partition administrator role.) of the first ("root") partition, also known as Root SOClosedSecurity officer - UKC partition administrator role.. Its password is specified during the CORE system bootstrap.

Root SOClosedSecurity officer - UKC partition administrator role. may create additional SOs in the Root partition. It also creates all other CORE partitions. All such partitions are created with two persistent users named so and user:

so
This user manages the partition.
Its password is assigned during the partition's creation.
It may join any other user group (see User Group) to obtain additional privileges reserved to the members of the group.
user
By default, it is a passwordless user that serves applications integrated with CORE Client libraries and are authenticated using the client certificate.
By default, it is granted unrestricted management and use of crypto material in the partition.
It cannot join any user group.

The settings of CORE user include:

  • Name
  • Alias (for a user that represents an SSOClosedSingle Sign-On user)
  • Role
  • Status (user is locked or active)
  • Dates of events in its life
  • Membership in User Groups

    • Note
    Membership in a User Group is granted or denied by managing the User Group's members. See User Groups Tab.

Managed Users

CORE supports the following options to manage its users:

Management of SSO User

The permissions of a user authenticated by an OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider are set indirectly by managing one of the following:

  • A CORE user group(s) that the user is a member of.
  • A native user that acts as its representative (alias) in the partition.

An SSOClosedSingle Sign-On user is granted all permissions that are granted to its group or alias.

User create
An SSOClosedSingle Sign-On user is associated with its partition and permissions using the following methods:
User modify
To modify permissions of an SSOClosedSingle Sign-On user, Edit permissions of its base or move it to a different base.
User show
To show permissions of an SSOClosedSingle Sign-On user, use the Show command of its base.
User delete
Delete the user's PI from its base.

Management of Native User

Users authenticated by CORE are called native users. Native CORE users are created and managed by the partition's SOClosedSecurity officer - UKC partition administrator role..

Notes
1. The first (default) users of a partition (so and user) are persistent. They can not be deleted.
2. For better security, in the CORE Client Stack applications, reassign the default user to a role with the least permissions required for executing crypto commands without user credentials.

User create
To create a native user, specify its credentials and role. See ucl user create.
User password modify
To change self-password, use ucl user change-pwd.
To reset the other user's password, use ucl user reset-pwd.
In extreme cases, the Root SOClosedSecurity officer - UKC partition administrator role. can change the password of any user in any partition by using the ucl user recover-pwd command.
User role modify
UCLClosedUnbound Command Language: to modify a user's role using UCLClosedUnbound Command Language, delete the username and create it again with the required role.
UI: you can use Change Role. In addition, you may change user's membership in user groups.
User group
The initial specification of a user's role may be expanded by adding the user to User Group(s). In such a case, the user is granted with all permissions associated with the group(s).
This capability applies to all users except the default user.
User show
To check the user's settings and status, use the ucl user show command in UCLClosedUnbound Command Language or use Show Permissions in UI.
User delete
To delete any other user except the default USER and SOClosedSecurity officer - UKC partition administrator role., use the ucl user delete command.

Management of LDAP User

In CORE , the user authenticated by LDAPClosedLightweight Directory Access Protocol is managed as a native user apart from its password management.

CORE User Authentication

CORE user authentication involves:

  1. Validation of Credentials.
  2. Validation of the 2nd authentication factor (2FAClosedTwo-factor authentication - Authentication method that requires both something a user has (for example, a certificate) and something the user knows (for example, a password)) which, in certain cases, can be optionally bypassed. See The 2nd Factor Validation Options.

Validation of Credentials

Every CORE service request must go along with credentials of the user or the CORE Users that is exchanged for the user credentials or for the OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol Access Token.

The credentials of the default CORE users are validated by CORE. The credentials of the managed CORE users may be validated by CORE , OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol or LDAPClosedLightweight Directory Access Protocol providers.

The following UI login page capture shows an example of CORE and OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol validation options presented to user in a particular system. For further login details, see UI Sign-in.

Note
To manage OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol providers in CORE , see OIDC Provider Management in CORE and here about integrating CORE with various OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol providers.

User sign-in options

Credentials Validation by OIDC Provider

Validation of a user credentials that has selected the "Continue with <OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol provider>" option is carried by the selected provider. A user may skip specifying the required partition. In such a case, CORE shall scan all partitions, collect all the partitions where the user is defined and select one of them as the initial login partition. The user could roam from there to any other of the collected partitions. See SSO User about managing such users.

Credentials Validation by CORE

Validation of a user credentials that has selected the "Continue with CORE" option is performed by the CORE server. CORE imposes the following username and password requirements:

Username is
Case-insensitive. It is displayed in lowercase characters.
Unique in the partition.
May contain characters that are specified in Username Permitted Characters.
Password complexity requirements are
Specified by the partition settings. See Password Requirement.

Credentials Validation by LDAP Provider

Validation of a user credentials is delegated to the LDAPClosedLightweight Directory Access Protocol provider. The LDAPClosedLightweight Directory Access Protocol-authenticated user must be defined in CORE using the same username as used by the LDAPClosedLightweight Directory Access Protocol provider. The user's password is defined and managed by the LDAPClosedLightweight Directory Access Protocol provider only. See LDAP Provider Settings.

Using CORE Access Token for Authentication

The CORE access token is JWTClosedJSON Web Token - means of representing claims transferred between two parties token issued by UNBOUND in exchange for the valid credentials or for the valid OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol Access token. It includes the following data:

partitions
A partition (or set of partitions) that this token is applicable with indication of the role assigned to the token's holder.
For example, "partitions": {"test": ["so"]} specifies that the token is applicable in test partition only and it grants its holder the permissions of SOClosedSecurity officer - UKC partition administrator role. role.
sub
Subject - full user name. A full user name combines user name with the partition name. For example, SOClosedSecurity officer - UKC partition administrator role. from partition test is specified so@test.
orig
Origin - IP address to whom this token has been provided.
iss
Issuer - The issuer (and the signer) of the token. Must be UNBOUND.
other JWTClosedJSON Web Token - means of representing claims transferred between two parties data
See example below

Example of a decoded payload section of a token:

{

"partitions": {"test": ["so"]},

"sub": "so@test",

"orig": "172.31.0.238",

"iss": "UNBOUND",

"is_refresh": false,

"use_ephemeral": false,

"exp": 1629134010,

"iat": 1629132210,

"jti": "d0c569a7-aaa3-4e7c-8a0c-26a2ed53b407"

}

Note that token already contains the full user name (<user>@<partition> in the "sub" field.

Obtaining CORE Token

To exchange the user credentials for the CORE JWTClosedJSON Web Token - means of representing claims transferred between two parties access token, use Get OAuth authentication token API with the following data:

'grant_type=password'

'username=<username>@<partition-name>'

'password=<user password>

If the TOTPClosedTime-based One Time Password 2nd authentication factor is required, add the following to the above parameters:

'otp=<TOTP code>'

Note

Username is full name. It specifies the username and the partition name.

Using CORE Token

The 2nd Factor Validation Options

CORE enforces validation of the 2nd authentication factor unless specifically configured to avoid such validation in the selected partitions. By design:

The following settings govern the selection of the required option:

This table summarizes the 2FAClosedTwo-factor authentication - Authentication method that requires both something a user has (for example, a certificate) and something the user knows (for example, a password) selection in a partition based on these settings.

setting default value Configurable options

no-cert

0 0 1 1

default-client

1 0 0 1
enforce-2fa 0 * * 0 1
2FAClosedTwo-factor authentication - Authentication method that requires both something a user has (for example, a certificate) and something the user knows (for example, a password) type in the partition     Certificate None TOTPClosedTime-based One Time Password

TOTP-based 2FA

Introduction

In the TOTPClosedTime-based One Time Password-based 2FAClosedTwo-factor authentication - Authentication method that requires both something a user has (for example, a certificate) and something the user knows (for example, a password), the 2nd factor is the proof that the user has access to the device where she installed the secret provided to her during the TOTPClosedTime-based One Time Password service enrollment. The proof doesn't disclose the secret and it becomes irrelevant after 60 to 120 seconds (based on the configuration).

TOTPClosedTime-based One Time Password uses the following components:

The OTPClosedOne-Time Password (or Pin) - a password that is valid for only one login session or transaction. code is the cryptographic derivative of user's unique secret and the current time-step. The TOTPClosedTime-based One Time Password generator on user's device refresh this code every 30 secondsl.

CORE Implementation of TOTP

Setup

To enforce the TOTPClosedTime-based One Time Password code as the 2nd authentication factor for CORE partition user, the partition SOClosedSecurity officer - UKC partition administrator role. must make the following preparations:

  1. Make sure that the system-wide Certificate-based 2FAClosedTwo-factor authentication - Authentication method that requires both something a user has (for example, a certificate) and something the user knows (for example, a password)  is disabled. See No-cert setting.
  2. Make sure that the default-client in the partition is enabled. See default-client.
  3. Enable enforce-2fa (see TOTP Settings). See Partition Settings in UI. As needed, extend the grace period (default - one time-step of 30 secs)

User Enrollment

To start using TOTPClosedTime-based One Time Password, user must register with the TOTPClosedTime-based One Time Password validator, obtain and install the shared secret.

Prerequisites:

  1. The partition settings as specified in Setup.
  2. The user had not yet enrolled to TOTPClosedTime-based One Time Password-based 2FAClosedTwo-factor authentication - Authentication method that requires both something a user has (for example, a certificate) and something the user knows (for example, a password) or her previous enrollment has been reset, see User TOTP 2FA Maintenance.

Procedure:

  1. User logins using UI by providing her credentials.
  2. CORE validates the credentials and creates user-specific secret.
  3. CORE UI :
  4. User opens Google Authenticator and scans the QR code.
  5. A new TOTPClosedTime-based One Time Password application appears in the Google Authenticator.

    6. For example, in the case of the above QR code, the Authenticator shows

    Unbound Security (so@test)
    <ephemeral OTP code>

  6. User enters the OTPClosedOne-Time Password (or Pin) - a password that is valid for only one login session or transaction. code requested in step#2 to complete the enrollment.

User Login

User login is 2 step procedure:

  1. Provide credentials in the targeted partition.
  2. When prompted, provide the currently displayed OTPClosedOne-Time Password (or Pin) - a password that is valid for only one login session or transaction. code.

User TOTP 2FA Maintenance

CORE provides the following options to force user's re-enrollment into TOTPClosedTime-based One Time Password service: