Authentication

Two entities authenticate to CipherTrust Manager web console UI, ksctl CLI and REST API: clients and users. Clients are applications that access CipherTrust Manager keys as needed to perform cryptographic or key management operations. Users are people who access CipherTrust Manager to perform configuration and key management tasks manually.

Any cryptographic or key management operation occurs over a client, and CipherTrust Manager always attempts to identify the client for these operations, and adds the client identity to the audit records if identified. Client authentication occurs when a client identity is found.

CipherTrust Manager authenticates users when a user identity is presented with the request. This authentication provides a mechanism to enforce permissions on a user, and an audit trail of a user's activities.

It is possible to only provide a client identity and not a user identity, in which case the client is the authenticated entity and its identity appears in the audit record. This authentication is appropriate for an automated client or a service account that requires no human interaction.

When a user identity is presented, with or without a client identity, only the user is authenticated. The client's actions are assumed to be performed on behalf of a user.

CipherTrust Manager authenticates a user or client, CipherTrust Manager checks the user or client's group membership, and applies the permissions associated with those groups.

There are three interfaces which CipherTrust Manager users and clients authenticate to:

• NAE

• KMIP

• Web. This comprises UI, CLI, and REST API access.

Client and User Identities

There are three types of clients:

• unregistered clients - are not registered with the CipherTrust Manager.

• public clients - are ksctl, NAE, Web-UI, and API playground. These clients are pre-registered with the CipherTrust Manager.

• confidential clients - are registered and able to securely authenticate with the CipherTrust Manager. For example, NAE, KMIP, and CTE clients. We recommend this client setting wherever possible.

Public clients and confidential clients have a client identity. The client identity is in the JSON Web Token (JWT) included in every request, so that CipherTrust Manager recognizes the client as a registered identity. Unregistered clients are allowed to make requests without an associated client identity.

Client identities are recorded in the audit records.

Only confidential clients can be authenticated. This is because public clients cannot store secrets, and CipherTrust Manager cannot validate secrets for an unregistered client.

User identities are tied to a user name, and can be authenticated through password or certificate. CipherTrust Manager authenticates local users directly, while an external identity provider authenticates Open ID Connect (OIDC) and Lightweight Directory Access Protocol (LDAP) users. LDAP and OIDC users have an associated user name on CipherTrust Manager, and their user identities are recorded in the audit records, as local user identities are.

You can control what client types a user can communicate through. By default, all three client types are allowed.

User Delegation and User Impersonation for KMIP and NAE

The KMIP and NAE interfaces require user authentication for backward compatibility with existing permissions configuration. KMIP and NAE clients, however, often operate in an automated manner without human interaction.

There are currently two ways to fulfill the user authentication requirement for a client:

• User delegation - This is providing a user's credentials or authorization grant when the client starts a new session with CipherTrust Manager.

• User impersonation - This is connecting with a client certificate containing a user's name in a defined field.

To enforce user delegation on an interface, set the following interface modes:

• tls-pw-req or "TLS, verify client cert, user must supply password"

• tls-cert-and-pw or "TLS, verify client cert, password is needed, user name in cert must match user name in authentication request"

To set user impersonation on an interface, set the following interface mode:

• tls-cert-pw-opt or "TLS, verify client cert, user name taken from client cert, auth request is optional"

LDAP and OIDC Connection Types

CipherTrust Manager supports LDAP and OIDC for authentication using dedicated connections for particular scenarios.

• An LDAP connection in the Connection Manager service for secure storage of credentials to authenticate CipherTrust Manager users.

• A LDAP connection in the Access Management service to authenticate CipherTrust Manager users. This connection is separate and additional to the Connection Manager LDAP connection.

• An OIDC Connection in Connection Manager to authenticate CTE Agents.

• A dedicated OIDC connection in Access Management to authenticate CipherTrust Manager users.

  Note

  If you create an OIDC connection through Access Management, a duplicate Connection Manager OIDC connection is visible, with no product. This duplicate is created for secure storage of credentials. We strongly recommend managing OIDC connections to authenticate CipherTrust Manager users through the Access Management UI menus and ksctl connections commands, and not Connection Manager.

Client Registration

When a client is successfully registered, the client is automatically added to the CipherTrust Manager, a client identity is assigned, and activity performed using that client identity can be monitored through records. The client becomes a confidential client.

ProtectFile, CTE, CipherTrust Data Protection Gateway (DPG), and KMIP clients need to be registered with the CipherTrust Manager to successfully authenticate and perform key and cryptographic operations. CipherTrust Manager currently allows unregistered clients of other types.

Client registration is supported with:

• CTE Agents

• CTE Userspace Agents

• CTE for Kubernetes Agents

• DPG

• Custom KMIP clients

• Custom NAE clients

• Custom REST API clients

Suggested Authentication for Users and Clients

• Require login with a user identity to any action performed manually by a person. This is already required and enforced for accessing ksctl CLI tool and CipherTrust Manager GUI.

• Set the following interface modes for NAE and KMIP. They are more secure, as they allow two factor authentication.

  • tls-pw-req or "TLS, verify client cert, user must supply password"

  • tls-cert-and-pw or "TLS, verify client cert, password is needed, user name in cert must match user name in authentication request"

• Register all clients that are possible to register, to assign a client identity.

• Register custom REST clients which are automated or represent a service account that does not require human interaction. Use the client identity to issue API tokens for such clients.