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.

Authentication Non AD/LDAP Setup

Basic Authentication

In a CT-VL system, the 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

Client Certificate Authentication

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

You may enable a client certificate authentication to verify that the machine has a valid cert to connect with CT-VL. You may also opt for a more sophisticated implementation.

Client Certificate Authentication supports two mode:

• Client Certificate with Identities

  In this mode, CT-VL verifies the client certificate. You can use the common name (CN) within a client cert and enter it as a user name in CT-VL. This also offers assigning granular permissions and associating specific keys to a client certificate.

  Example

      curl -v -k -X POST -H 'Content-Type: application/json' -d '{"data": "XXXX-XXX-XXX-XXX", "tokengroup": "group1", "tokentemplate": "template1"}' --cert cert.pem --key key.pem https://CtvlIpAddress/vts/rest/v2.0/tokenize
  

• Client Certificate without Identities

  In this mode, CT-VL doesn't verify the client certificate. While using client certificate without identities, you must provide a username/password with the certificate, which can be a security vulnerability that the client certificates intends to prevent. The option to use certificates without identities is provided to maintain backward compatibility with the earlier basic authentication flow.

  Example

      curl -k -X POST -H 'Content-Type: application/json' -d '{"data": "XXXX-XXX-XXX-XXX", "tokengroup": "group1", "tokentemplate": "template1"}' --cert cert.pem --key key.pem https://ctvliporhostname/vts/rest/v2.0/tokenize -u username:password
  

  Note

  We strongly recommend using client certificates with identities.

To implement client certificates with granular permissions, ensure the following:

• An established in-house Certificate Authority (CA).

• An exportable CA certificate.

• Client certificates (signed by the CA) containing a common name (CN).

• Go to the CT-VL CLI to:

  Note

  In Client Certificate with Identities mode, CT-VL verifies the client certificate. If the client certificate is signed by a single root CA or a different chain of CAs, you must add the complete CA chain to CT-VL using the command below. The chain must include all intermediate CAs, starting with the one that issued the server certificate, and must end with the root CA.

  • Upload the CA cert to CT-VL:

        vts> client_certificate --upload
    

  • Enable the client certs with ID option:

        vts> client_certificate --enable-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 only supports RSA Algorithm for Certificates and CA. All client certificates must be in PEM format. Moreover, CT-VL does not support auto renewal of a certificate or CA. When a cert or CA expires, upload the updated CA or chain of CA's, and restart the vts service.

Authentication in AD/LDAP Setup

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.

Basic Authentication

In a CT-VL system, the REST APIs and the application developer who wishes to incorporate CT-VL services into an application, a basic user account consists the following, where the user exists on the LDAP server:

• user name/identifier

• password

Client Certificate Authentication

Client certificate authentication is same for Non AD/LDAP Setup and AD/LDAP Setup. For details, see Client Certificate Authentication

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.