User Authentication

A user represents a person or an application that manages or uses elements of the CORE system. CORE supports the following authentication methods for user credentials:

The following UI login-in dialog capture presents to a user options to sign-in as an internal or LDAPClosedLightweight Directory Access Protocol user (by selecting "Unbound" option ) or use one of the OpenID providers that are registered with the system. See UI Sign-in.

User sign-in options

Internal Users

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

The Root SOClosedSecurity officer - UKC partition administrator role. creates the CORE partitions. Each partition is created with two persistent internal users named:

This user manages the partition.
Its password is assigned during the partition's creation.
It may join any other user group (see User Group) and obtain privileges reserved to the members of the group.
By default, it is a passwordless user that serves applications which are authenticated using a client certificate only.
- To block this capability, set its password.
By default, it is granted unrestricted management and use of crypto material in the partition.
- To block this capability, reassigned it to a custom role (see Custom Roles ).
It cannot join any user group.

All other users of a partition are created and managed by the default SOClosedSecurity officer - UKC partition administrator role. and other SOs that are created in the partition.

Management of Internal User

The settings of an internal CORE user contain:

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

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

Internal CORE users are created and managed by the partition's default SOClosedSecurity officer - UKC partition administrator role. or any other user of the partition with the SOClosedSecurity officer - UKC partition administrator role. privileges.

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 an internal user, specify its credentials and role. See ucl user create.
User password modify
To change your 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 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.

1. The initial specification of a user's role may be expanded by adding the user to User Groups (see User Group) that specify additional roles. This capability applies to all users except the default user.
2. User membership in User Group(s) is specified by adding the user's name to the relevant User Group(s).

Internal User Authentication

The credentials of an internal user may be carried explicitly with each request or once confirmed, may be substituted by the CORE token that must be provided with each request and periodically refreshed or replaced with a new token.

Credentials of Internal User

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

Authentication with Credentials

Each request carries the user name and its password. Examples:

CLIClosedCommand Line Interface
specify --user <name> -w <password> in each command.
For example,

ucl sign-code --file C:\tmp\test.exe -n my-sign-key --user tester -w ********

Provide user name and password in the sign-in procedure.
The credentials are substituted by CORE token that is used in each request and its validity is periodically extended as long as your browser session is not terminated.

Authentication with Token

Once obtained, CORE token may be used instead of credentials. It must be issued and signed by UNBOUND .The CORE token is JWTClosedJSON Web Token - means of representing claims transferred between two parties compliant. It includes the following data:

A partition (or set of partitions) that this token is applicable
Full user name (full user name combines user name and the partition name where this user is registered. For example, SOClosedSecurity officer - UKC partition administrator role. from partition test is specified so@test).
IP address to whom this token has been provided.
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": "",

"iss": "UNBOUND",

"is_refresh": false,
"use_ephemeral": false,

"exp": 1629134010,

"iat": 1629132210,

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


Note that token already contains the user and partition names. To use a token in CLIClosedCommand Line Interface commands, use the following syntax to provide the user's credentials.

-w {\"token\":\"<JWT token in Base64>\"}

For example:

ucl sign-code --file C:\tmp\test.exe -n my-sign-key -w {\"token\":\"eyJraWQiOiIweDAwNTEyODk0MzQ2MTBhNGVhYyIsImFsZyI6IkVTMjU2In0. eyJwYXJ0aXRpb25zIjp7InRlc3QiOlsic28iXX0sInN1YiI6InNvQHRlc3Qi LCJvcmlnIjoiMTcyLjMxLjAuMjM4IiwiaXNzIjoiVU5CT1VORCIsImlzX3Jl ZnJlc2giOmZhbHNlLCJ1c2VfZXBoZW1lcmFsIjpmYWxzZSwiZXhwIjoxNjI5 MTM0MDEwLCJpYXQiOjE2MjkxMzIyMTAsImp0aSI6ImQwYzU2OWE3LWFhYTMt NGU3Yy04YTBjLTI2YTJlZDUzYjQwNyJ9.

Note: Token has no line breaks. The line breaks were added for clarity.

SSO Users

CORE users authenticated by OpenID Connect (OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol) provider are called SSOClosedSingle Sign-On users. An SSOClosedSingle Sign-On user may be a member in multiple partitions, and in a partition, it may be a member of multiple user groups and/or associated with a particular Internal User (the "alias").

See here for details about integrating with various OIDCClosedOpenID Connect is identity layer on top of the OAuth 2.0 protocol providers.

SSO User Management

An SSOClosedSingle Sign-On user is managed indirectly by managing one of the following:

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

We use the term "base" to specify either of the above options. An SSOClosedSingle Sign-On user is granted all permissions that are granted to its base.

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.

LDAP Users

AuthenticationClosedProcess used to achieve sufficient confidence in the binding between the Entity and the presented Identity. of an LDAPClosedLightweight Directory Access Protocol user is delegated to the LDAPClosedLightweight Directory Access Protocol provider.

LDAPClosedLightweight Directory Access Protocol users are defined and managed as Internal Users except the following: