Users

Users are the authenticated entities that make REST calls, or access the CipherTrust Data Security Platform Service GUI or CLI. To authenticate to the REST API, you POST the user credentials to an authentication endpoint, and receive an API token, which you can use in subsequent API calls.

The operations which users are allowed to perform are controlled through group membership.

Managing Users

Users can be created and managed through the web console, ksctl CLI, or REST API.

On launch, a single user exists. This is the Data Protection on Demand (DPoD) user which provisioned the CDSPaaS service, and logs in through DPoD. This user can create, modify and delete other users.

The following options are available for managing users:

• Create

• Delete

• Get a single record

• List records

• Modify

Creating a Local User through GUI

Perform the following steps to create a user through the GUI:

1. Navigate to Access Management > Users.

2. Click Add User available on the top right corner of the screen. The Add User screen appears.

3. Select the Connection Type to create a user:

   • Local Account - Select this option and specify the following:

     • Full Name

     • Username

     • Email

     • Password

     • Password Match

4. Click Create. A user is created and will appear in the list of users available on the Users page.

Creating a Local User through ksctl CLI

Use the below ksctl CLI to create a user named "bob":

ksctl users create --name bob --pword bob

The response looks like:

    {
        "created_at": "2022-01-24T06:53:27.245528Z",
        "email": "bob@local",
        "last_login": null,
        "logins_count": 0,
        "name": "bob",
        "nickname": "bob",
        "updated_at": "2022-01-24T06:53:27.245528Z",
        "user_id": "local|c6537abe-a266-4833-9d60-b9713812136e",
        "username": "bob",
        "failed_logins_count": 0,
        "account_lockout_at": null,
        "failed_logins_initial_attempt_at": null,
        "last_failed_login_at": null,
        "password_changed_at": "2022-01-24T06:53:27.240767Z",
        "password_change_required": false,
        "certificate_subject_dn": "",
        "enable_cert_auth": false,
        "auth_domain": "00000000-0000-0000-0000-000000000000",
        "login_flags": {
            "prevent_ui_login": false
        },
        "allowed_auth_methods": [
            "password"
        ]
    }

Setting Expiration Date for Users

The expires_at flag is added to set the expiration date for the local users to limit the user account to a certain period. This field is optional. After the expiration date has been reached, the access permissions for that user will be revoked. The user will no longer have access to the CipherTrust Manager. Only members of the admin and User Admins groups can add or modify the expiration date for an existing local user account. If the expiration date is extended or removed for an already expired account, the account will be active again.

Here are the examples of date-time format:

• 2002-10-02T10:00:00-05:00

• 2002-10-02T15:00:00Z

• 2002-10-02T15:00:00.05Z

The CipherTrust Manager throws an error if you set the expiration date before the current time. You can set the expiration date for both new users as well as existing users.

For new users

For new users, run:

Request example 1 (create user with valid date)

ksctl users create --name "john" --expires-at "2023-01-30T10:30:35.421799Z"

Response

{
    "created_at": "2023-01-24T08:14:57.853232Z",
    "email": "john@local",
    "last_login": null,
    "logins_count": 0,
    "name": "john",
    "nickname": "john",
    "updated_at": "2023-01-24T08:14:57.853232Z",
    "user_id": "local|c3209b29-0343-4a10-a9b6-bd5674580518",
    "username": "john",
    "failed_logins_count": 0,
    "account_lockout_at": null,
    "failed_logins_initial_attempt_at": null,
    "last_failed_login_at": null,
    "password_changed_at": "2023-01-24T08:14:57.833508Z",
    "password_change_required": false,
    "certificate_subject_dn": "",
    "enable_cert_auth": false,
    "auth_domain": "00000000-0000-0000-0000-000000000000",
    "login_flags": {
            "prevent_ui_login": false
    },
    "allowed_auth_methods": [
            "password"
    ],
    "expires_at": "2023-01-30T10:30:35Z",
    "allowed_client_types": [
            "unregistered",
            "public",
            "confidential"
    ]
}

Request example 2 (create user with expiration date before the current time)

ksctl users create --name "james" --expires-at "2021-01-30T10:30:35.421799Z"

Response

{
    "code": 9,
    "codeDesc": "NCERRInvalidParamValue",
    "message": "expires_at cannot be before current time"
}

For existing users

For existing users, run:

Request example 1 (modify user with valid date)

ksctl users modify --id "local|c3209b29-0343-4a10-a9b6-bd5674580518" --expires-at "2023-01-28T10:30:35.421799Z"

Response

{
    "created_at": "2023-01-24T08:18:57.929628Z",
    "email": "john@local",
    "last_login": null,
    "logins_count": 0,
    "name": "john",
    "nickname": "john",
    "updated_at": "2023-01-24T08:18:57.929628Z",
    "user_id": "local|c3209b29-0343-4a10-a9b6-bd5674580518",
    "username": "john",
    "failed_logins_count": 0,
    "account_lockout_at": null,
    "failed_logins_initial_attempt_at": null,
    "last_failed_login_at": null,
    "password_changed_at": "2023-01-24T08:18:57.915523Z",
    "password_change_required": false,
    "certificate_subject_dn": "",
    "enable_cert_auth": false,
    "login_flags": {
        "prevent_ui_login": false
    },
    "allowed_auth_methods": [
        "password"
    ],
    "expires_at": "2023-01-28T10:30:35Z",
    "allowed_client_types": [
        "unregistered",
        "public",
        "confidential"
    ]
}

Request example 2 (modify user with invalid date)

ksctl users modify --id "local|cdb01da2-56d1-4d30-8c8a-4cc73a684b2a" --expires-at "1-01-2023"

Response

Invalid date format for Expiry date: parsing time "1-01-2023" as "2006-01-02T15:04:05Z07:00": cannot parse "-2023" as "2006"

Managing Allowed Client Types for Users

The allowed_client_types flag is added to manage the list of client types that are allowed to authenticate the users through their credentials. This field is optional.

By default, the CipherTrust Data Security Platform Service allows all clients types:

• unregistered clients - are not registered with the CipherTrust Data Security Platform Service.

• public clients - are ksctl, Web-UI, and API playground. These clients are pre-registered with the CipherTrust Data Security Platform Service.

• confidential clients - are able to securely authenticate with the CipherTrust Data Security Platform Service. For example, NAE, KMIP, and CTE clients.

If you set the allowed_client_types flag to empty, no client can authenticate the user to log on to the CipherTrust Data Security Platform Service.

You can set any combination of client types based on your requirements.

Example Request

ksctl users create --username chanakya --pword KeySecure_1 --allowed-client-types confidential,public

Example Response

{
    "created_at": "2022-12-05T13:29:29.325474Z",
    "email": "chanakya@local",
    "last_login": null,
    "logins_count": 0,
    "name": "chanakya",
    "nickname": "chanakya",
    "updated_at": "2022-12-05T13:29:29.325474Z",
    "user_id": "local|726720ee-c597-4582-92c0-31f2c2f53947",
    "username": "chanakya",
    "failed_logins_count": 0,
    "account_lockout_at": null,
    "failed_logins_initial_attempt_at": null,
    "last_failed_login_at": null,
    "password_changed_at": "2022-12-05T13:29:29.321738Z",
    "password_change_required": false,
    "certificate_subject_dn": "",
    "enable_cert_auth": false,
    "auth_domain": "00000000-0000-0000-0000-000000000000",
    "login_flags": {
        "prevent_ui_login": false
    },
    "allowed_auth_methods": [
        "password"
    ],
    "allowed_client_types": [
        "confidential",
        "public"
    ]
}

Adding Single Sign On Users

You can add some Data Protection on Demand (DPoD) users to the CDSPaaS tenant, so that they can log in with their DPoD usernames and passwords to the CipherTrust Data Security Platform Service UI.

Compatible DPoD users are tenant administrators or application owners within the DPoD subscriber tenant which hosts the CDSPaaS tenant.

1. Click the service name in DPoD to launch CDSPaaS web console UI in a separate browser tab.

2. On the login page, click Log In with DPoD.

3. Enter the Email and Password of the desired DPoD user.

   The error "Access denied: a SSO user must be a member of at least one group to access the tenant. Ask your tenant's user administrator for access." is displayed, as expected.

4. In a separate session, log in to CDSPaaS as a user in the admin or User Admins group.

   Tip

   Usually, the DPoD user who provisioned the service is in the admin group.

5. Navigate to Access Management > Users.

   A local user is present associated to the DPoD user who attempted to login, with the same username.

6. Assign the new user to at least one group.

   1. Click the desired Username in the table to view the user details.

   2. Expand the Group Memberships section.

   3. Click Add Group.

   4. Enable the checkbox for any desired group(s). You can search for a group by name.

      Tip

      We recommend CCKM Users or Key Users for basic cryptographic key usage. Consult the Groups page for details about the available system-defined groups.

   5. Click Add Group to confirm.

The new single sign-on user should now be able to access the CDSPaaS tenant and begin using keys.

Preventing Users from UI Login

The CipherTrust Data Security Platform Service allows you to prevent the UI login for users if you set the prevent_ui_login property to true while creating the user. By default, this property is set to false.

You can change the value of prevent_ui_login property while updating the user.