Understanding CT-VL Authentication and Authorization

CT-VL Users

CT-VL makes no official distinctions between “human user accounts,” for real people, and “service user accounts,” representing daemons, scripts, processes, applications, or groups within applications with programmatic access to CT-VL services. Both are referred to as “users.”

From the point of view of the CT-VL system, the CT-VL REST APIs and the application developer who wishes to incorporate CT-VL services into an application, a basic user account consists of:

• user name/identifier

• password or client certificate (If authentication is done from a client certificate, the password is not used.)

These attributes form the basis of user authentication.

User Profiles

Users can be human or servers.

Human users

Human users include the administrators, staff, and developers who use the CT-VL interface and/or the CT-VL APIs to install, configure, integrate, and maintain its services.

There are also human “end-users,” such as employees in a customer service department who may be assigned to a CT-VL user group authorized to detokenize credit cards, and to view the last four digits of the card, based on the data mask that was applied to their user group.

Service users

However, most CT-VL usage consists of service users, where various servers and applications pass authentication, tokenization, encryption, and key information between themselves to complete a transaction of some kind.

For example:

A company may set up a structure to assign a financial application as User1 with a certain number of keys to perform certain operations. Within that same application, User2 might be a process that uses key2 to tokenize/detokenize credit cards, and User3 might be used to encrypt/decrypt social security numbers with key3.

CT-VL Authentication Overview

CT-VL first seeks to validate whether the user credentials match entries in its local database. If not, and if AD/LDAP is configured, then it will check against AD/LDAP settings. When authentication is successful, the system will also check for CT-VL role assignment, any key association, and any active permissions.

AD/LDAP and User Authentication

Companies can choose to use Active Directory/LDAP to store both human and service user accounts for CT-VL, to have a centralized way to manage them. If this approach is chosen, then the implementation involves cooperation between:

• The network administrator, to configure the connection between AD/LDAP and CT-VL.

• The AD/LDAP administrator and other organizational decision makers who decide which users should be imported into the CT-VL database, how to group them, what user group names to assign them in AD/LDAP, and what types of permissions should be granted on a group and/or individual basis.

• The CT-VL GUI administrator, who must manually enter the designated user group names into the CT-VL GUI before the user accounts are imported.

Client Certificates and User Authentication

Client certificates can be used for authentication. The certificate itself is a credential and can be safer than a password, as it cannot be easily shared, duplicated, written on a sticky note, or otherwise carelessly exposed.

Companies might enable simple client cert authentication, to verify that a machine has a valid cert to connect with CT-VL. Or they may choose a more sophisticated implementation.

With CT-VL, it is possible to use the common name (CN) inside a client cert and enter it into CT-VL as a user name, thereby taking advantage of the ability to assign granular permissions and/or associate particular keys to a client certificate. This is known as using a client certificate “with identities.”

To implement client certs with granular permissions, an organization would need to:

• Have established an in-house Certificate Authority (CA).

• Have an exportable CA cert.

• Issue any number of client certs (signed by the CA) that each contain a common name (CN).

• Go to the CT-VL CLI to:

  • Upload the CA cert to CT-VL.

  • Enable using client certs with ID.

• Use the CT-VL graphical user interface (GUI) for:

  • Creating users and entering common names as user names (or import from Active Directory for LDAP).

  • Managing user permissions (If importing from LDAP, you can use the CT-VL CLI setting to designate a user group as the “active” user group thereby activating all members of the group.)

  • Associating key(s) with the cert/user.

  • Assigning permissions to the cert/user.

  Note

  CT-VL requires that all client certificates be in PEM format.

CT-VL Authorization Overview

CT-VL employs a multi-layered security model with separation of duties and granular permissions settings built in to it. It is also flexible, adaptive to individual corporate structures and policies. This structure implies some inherent complexity, but the concepts below form the foundational assumptions.

CT-VL Roles

When a user is created in CT-VL, it can be assigned one or more of the following core CT-VL roles:

• Superuser: Can perform both read and write actions in the CT-VL GUI.
  
  Superusers are GUI administrators who manage users, user groups, keys, tokenization groups, tokenization templates, data masks, and character sets. Superusers associate users with key(s) and assign the crypto, key, and tokenization permissions to other users. Superusers are automatically also “Staff.”

• Staff: Users with read-only permission to the CT-VL GUI.

• Active: Users must be “active” in order to have encryption, key, or tokenization permissions. Active users are those authorized to use the CT-VL REST APIs.

The role-based permissions (Active/Staff/Superuser) are incremental. With no role assigned, the user cannot access any CT-VL functionality. (This is equivalent to being deleted, but the information is retained in the database for possible reactivation.)

Key-Aware Permissions Matrix

The GUI Administrator can assign permissions based on user (or user group), action, and key.

In the following example, User CTSuser1 may encrypt, decrypt, tokenize and detokenize with symmetric key Sym_key1.

Other (Non-Key Dependent) Permissions

Users or user groups can be authorized to dynamically create and/or import key names and key material on the CipherTrust Manager, under the "Other Permissions" column of the Permissions main page.

• Create key: Creates the key name and key material on the CipherTrust Manager; the key name will be listed in the CT-VL GUI.

• Import key: Used to import any key from one CipherTrust Manager to another, or from an external system to the CipherTrust Manager. The imported key name will be listed in the CT-VL GUI.

This Tokenize/Detokenize feature is used during upgrade from earlier versions of CT-VL, as its grandfathers in the global tokenize/detokenize feature that was used previously.

Understanding CT-VL User Groups and Permissions

• CT-VL role-based user groups:

The three core CT-VL roles (Superuser/Staff/Active) are also three required core CT-VL user groups. An organization may choose to assign different group names, but the meanings are retained. CT-VL GUI administrators must create at least three user groups that correspond to the roles Superuser/Staff/Active.

• Assigning users to user groups in two different ways:

  • If importing from AD/LDAP, users will be sorted into their role groups from the CLI.

  • If entering users directly in the GUI, the administrator will assign the role(s) on the user’s page and then check the appropriate group(s).

• Adding more user groups:

Additional groups can be added to CT-VL for organizational purposes.

• Assigning group permissions:

Key-based and non-key-dependent permissions can be assigned at the user group level or the user level, but assigning at the group level is recommended.

• Permissions are additive:

Individual and group permissions are additive. For example, suppose Joe is a member of the user group “Finance,” which has permission to tokenize credit card numbers, and Joe is also a team lead granted user-level permission to detokenize. In total, Joe can tokenize and detokenize.

Users, User Groups, and Tokenization Groups

To allow for abbreviated Tokenization REST API calls and to enable division of an organization into sub-organization either by location or department, CT-VL adds a so-called “tokenization group” concept.

So, there could be a user group “Finance” in San Francisco, and another “Finance” user group in Paris, each associated with its own tokenization group.