CORE IAM Concepts
Introduction
CORE follows the OAuth 2.0 concepts of authentication and authorization based on clients and users. A client represents a device while a user represents a person or an application using the system. Many different users/applications can connect to the specific partition of the system using the same device, and each would get individual permissions based on the considerations outlined below and detailed in the following sections.
Client (device)
- Client Authentication
Process used to achieve sufficient confidence in the binding between the Entity and the presented Identity.
- A CORE client's name is tied to the designated CORE partition in the Subject settings of X.509 certificate. Validation of the certificate is performed by asserting the certificate's validity and that the client name in the certificate is indeed registered on CORE with the partition specified in the certificate.
-
Note
In general, the CORE client certificate is signed by the CORE CA. Besides, it may be signed by an external CA that is mandated by the CORE customer. In such a case, the Subject field must be properly set as specified in External Client. - Client Authorization
- The possession of a valid certificate grants its holder access to the partition specified in the certificate. Yet a holder of the certificate might be unauthorized to use the certificate. For example, when the client certificate is used by a device whose IP address is not listed among the IP addresses permitted to use the certificate. Client authorization makes sure that it is used by an authorized holder.
User (application)
- User Authentication
Process used to achieve sufficient confidence in the binding between the Entity and the presented Identity.
- An SSO
Single Sign-On user is authenticated by OpenId Connect (OIDC
OpenID Connect is identity layer on top of the OAuth 2.0 protocol) provider.
- An LDAP
Lightweight Directory Access Protocol user's name is checked by CORE and the credentials are validated by the LDAP
Lightweight Directory Access Protocol provider,
- Credentials of the CORE internal user are validated by CORE.
- User Authorization
- The authenticated user is mapped to a set of permissions assigned to the user.
Partition Policy
Meeting the IAM authorization requirements is a necessary but not sufficient condition to perform the required operation. An organization using CORE partition may impose partition pinpointed or wide range restrictions and quorum-based approvals:
- A fine-grained policy may prohibit the use of certain key types, crypto algorithms, and methods.
- A coarse-grained policy may block a complete class of operations, such as the ability to generate any type of key material by non-SO
Security officer - UKC partition administrator role. users.
- Likewise, the execution of operations that are considered sensitive by the organization may be postponed pending the partition's quorum approval.
Authentication Steps
To enter the CORE service area, an applicant must pass the following checkpoints:
- Authentication
Process used to achieve sufficient confidence in the binding between the Entity and the presented Identity. of the device that originates the request.
- Authorization of the device that originates the request.
- Authentication
Process used to achieve sufficient confidence in the binding between the Entity and the presented Identity. of the user that issues the request.
Depending on whether an application is based on the CORE Client Stack or the rest of CORE API such as RESTRepresentational State Transfer (REST) - an architectural style that defines a set of constraints and properties based on HTTP. Web Services that conform to the REST architectural style, or RESTful web services, provide interoperability between computer systems on the Internet. and KMIP
Key Management Interoperability Protocol - an extensible communication protocol that defines message formats for the manipulation of cryptographic keys on a key management server, a partition SO
Security officer - UKC partition administrator role. may permit bypassing some of the checkpoints:
Application is based on | Device Authentication |
Device Authorization |
User Authentication |
---|---|---|---|
CORE Client Stack | mandatory | optional - see note 1 | |
CORE REST![]() ![]() |
optional - see note 2 | mandatory |
Note 1.
If user credentials are omitted, the application is granted permissions that are assigned to the default user of the partition which is specified in the provided certificate.
Note 2.
By default, a client certificate is mandatory. To exclude a partition user from presenting the partition's client certificate, see Exemption from Certificate Possession.
If the client certificate is omitted, the targeted partition must be specified using one of the following methods: explicitly, encoded in the user's name, or derived from the user's personal information provided by the OIDCOpenID Connect is identity layer on top of the OAuth 2.0 protocol Provider.
Authorization granularity
Once an applicant is allowed to enter the CORE service area, the system assembles the list of permissions granted to the applicant.
Permission ties up a group of crypto objects with the set of allowed management and crypto operations. For example, to perform a crypto operation using a key, both the key and the operation must be specified by one of the permissions that are granted to the user.
Note
The [specific key, specific operation]
granularity of permission enables a partition's SOSecurity officer - UKC partition administrator role. to implement the Principle of the Least Privilege (PoLP) policy in the partition.
Permissions are granted to a user using the following methods:
- directly, by assigning a custom CORE Role to a user. A role is a collection of permissions that are granted to the holder of the role.
- indirectly, by its membership in User Group(s). A user group specifies all roles granted to its members.
- combining both the Role and the membership.
While the assertion of permission uses fine-grained validation (specific object, specific operation), the management of permissions is carried at coarser granularity by tying up a set of the permitted operations and an arbitrary group tag. By attaching a group tag to a key we permit its use by the operations associated with the tag. The (key, tag) relationship is many-to-many: many keys may be tagged with the same tag, and multiple tags may be attached to one key.
Exemption from Certificate Possession
Applications that are not using CORE Client Software may be exempted from presenting the client certificate of the targeted partition. It may be declared globally and overridden by SOs of partitions.
- Global setting.
Root SOSecurity officer - UKC partition administrator role. should enable the system's
no-cert
setting. See No-cert. - Per partition setting.
Partition SOSecurity officer - UKC partition administrator role. can override the global setting by enabling the partition's
default-client
setting. See Allow default-client.
Quickstart 1
In the following quickstart, we define a system that mandates client certificate only for the Root partition. Assume that the Root SOSecurity officer - UKC partition administrator role. password is Password1!
- Make sure that access to the Root partition by REST
Representational State Transfer (REST) - an architectural style that defines a set of constraints and properties based on HTTP. Web Services that conform to the REST architectural style, or RESTful web services, provide interoperability between computer systems on the Internet. API requires the Root partition's client certificate:
- Allow accessing all other partitions without their client certificates:
ucl settings set -p root -k default-client -v 0 -w Password1!
ucl system-settings set -k no-cert -v 1 -w Password1!
Devices accessing all other partitions in the system that use the default (undefined) value of the default_client
will be exempted from client certificate possession in the RESTRepresentational State Transfer (REST) - an architectural style that defines a set of constraints and properties based on HTTP. Web Services that conform to the REST architectural style, or RESTful web services, provide interoperability between computer systems on the Internet. API applications.
Quickstart 2
In the following quickstart, we define a system that mandates client certificates for all partitions, except partition P.
- Enforce certificate requirement on all partitions (this is the default setting of the
no-cert
): - Make sure that access to the Root partition by REST
Representational State Transfer (REST) - an architectural style that defines a set of constraints and properties based on HTTP. Web Services that conform to the REST architectural style, or RESTful web services, provide interoperability between computer systems on the Internet. API requires the Root partition's client certificate:
ucl system-settings set -k no-cert -v 0 -w Password1!
ucl settings set -p P -k default-client -v 1 -w *******