Skip to main content
Skip table of contents

Access groups

DCT Access Groups provides global user management and permissions for all objects within the connected ecosystem. This entitlement authorization system is both managed and enforced for operations triggered through DCT APIs and/or user interface. 

This is mutually exclusive to the permissions system on local Continuous Data, Continuous Compliance, and Self-Service applications. However, DCT’s system does enable users to operate on objects within local engines, as DCT will perform those operations on the users behalf, if the user has the correct permissions within DCT.

Access Group structure

Access Groups represent a singular, global set of users and permissions. It operates as the point to manage access and authorization for all users; both human users accessing the DCT UI, and automation by means of generating API keys to leverage the DCT APIs. 

Access Groups are comprised of two sets of configurable objects, accounts and roles.

Access Groups can have any number of accounts and roles (e.g. a role pairing DevOps permission sets for a subset of VDBs, and a role pairing Compliance permission sets for a subset of Compliance Jobs).

Accounts

Accounts represent generalized users; a human user, an API key, or both. An account can belong to multiple Access Groups, but it is strongly recommended to maintain a dedicated Access Group for an account or group of accounts, to prevent privilege creep. Accounts can be attributed to Access Groups via LDAP/Active Directory Group attributes, DCT Account Tags, or manually adding accounts. 

Roles

Roles can be considered a collection of permissions. Attributing a role into an Access Group first starts by identifying a “mode”. DCT currently supports both simple and scoped modes for roles, with the plan to introduce advanced mode in a subsequent release. 

Simple mode is meant to apply general sets of permissions as universal, for all applicable types of objects. For example, a simple mode with a “Monitor” set of permissions will give viewing rights for all VDBs, dSources, environments, etc.

Scoped mode is more closely related to the Continuous Data Engine model of applying a set of permissions on specific groups of applicable objects. For example, scoped mode with a “DevOps” set of permissions grants view, refresh, provision, etc. permissions over the defined set of VDBs. Scoped roles can be automated.

In addition to modes, roles can be configured with role types. The current release only includes “standard” roles, which are comprised of:

Admin role

NONE
DSOURCE/SNAPSHOT,VDB/MANAGE_TAGS,MASKING_JOB_SET/SET_TAGS_AT_OBJECT_CREATION,BOOKMARK/SET_TAGS_AT_OBJECT_CREATION,VDB/UPDATE,MASKING_JOB_SET/REMOVE_JOB,LDAP/VALIDATE,DSOURCE/UPDATE,DSOURCE_CONSUMPTION_REPORT/READ,ENVIRONMENT/DISABLE,GLOBAL_PROPERTIES/READ,VDB_GROUP/DELETE,GLOBAL_PROPERTIES/UPDATE,ACCOUNT/DELETE,DATABASE_TEMPLATE/UPDATE,ENVIRONMENT/REFRESH,CDB/MANAGE_TAGS,VDB/CREATE,JOB/READ,DATABASE_TEMPLATE/READ,REPORT_SCHEDULE/READ,VDB/PROVISION,DSOURCE/MANAGE_TAGS,VDB/SNAPSHOT,STORAGE_SUMMARY_REPORT/READ,DSOURCE/PROVISION,SAML/UPDATE,VDB/REFRESH,ACCOUNT/MANAGE_TAGS,ACCOUNT/PASSWORD_RESET,ENGINE/UPDATE,ACCOUNT/READ,BOOKMARK/DELETE,REPORT_SCHEDULE/CREATE,VDB_GROUP/MANAGE_TAGS,PASSWORD_POLICY/READ,VDB_GROUP/READ,VCDB/READ,MASKING_JOB/READ,CDB/READ,JOB/ABANDON,CONNECTIVITY_CHECK/EXECUTE,MASKING_JOB_SET/COPY,API_CLASSIFICATION/UPDATE,ENGINE/CREATE_ENVIRONMENT,ACCESS_GROUP/UPDATE,VDB/DELETE,VAULT/DELETE,MASKING_JOB/DELETE,API_USAGE_REPORT/READ,MASKING_JOB_SET/UPDATE,DSOURCE/READ,VDB_GROUP/CREATE,LDAP/UPDATE,ACCOUNT/CREATE,SMTP_CONFIG/VALIDATE,CONNECTOR/UPDATE,VDB/READ,SMTP_CONFIG/READ,ENVIRONMENT/READ,ROLE/READ,SOURCE/UPDATE,ENVIRONMENT/DELETE,ENVIRONMENT/CREATE,VDB/START,VDB/DISABLE,VAULT/READ,VDB_GROUP/REFRESH,BOOKMARK/READ,DATABASE_TEMPLATE/IMPORT,DATABASE_TEMPLATE/UNDO_IMPORT,ACCESS_GROUP/DELETE,VAULT/CREATE,VDB/ENABLE,ENGINE/SET_TAGS_AT_OBJECT_CREATION,SOURCE/MANAGE_TAGS,BOOKMARK/UPDATE,VCDB/UPDATE,VDB/SET_TAGS_AT_OBJECT_CREATION,DSOURCE_USAGE_REPORT/READ,SAML/READ,MASKING_JOB_SET/MANAGE_TAGS,ENVIRONMENT/MANAGE_TAGS,REPORT_SCHEDULE/DELETE,DSOURCE/REFRESH,DATABASE_TEMPLATE/DELETE,VDB/STOP,ACCOUNT/UPDATE,ENGINE/MANAGE_TAGS,BOOKMARK/CREATE,PASSWORD_POLICY/UPDATE,MASKING_JOB_SET/DELETE,ACCESS_GROUP/READ,VDB_GROUP/UPDATE,ENVIRONMENT/SET_TAGS_AT_OBJECT_CREATION,VDB/CREATE_VDBGROUP,DATABASE_TEMPLATE/CREATE,VDB_GROUP/SET_TAGS_AT_OBJECT_CREATION,LDAP/READ,BOOKMARK/REFRESH_FROM_BOOKMARK,REPORT_SCHEDULE/UPDATE,BOOKMARK/PROVISION_FROM_BOOKMARK,ENVIRONMENT/ENABLE,VDB/CREATE_BOOKMARK,VCDB/MANAGE_TAGS,MASKING_JOB/UPDATE,BOOKMARK/MANAGE_TAGS,VDB_INVENTORY_REPORT/READ,ENGINE/CREATE,CONNECTOR/EXECUTE,ENVIRONMENT/UPDATE,PRODUCT_INFO/READ,SMTP_CONFIG/UPDATE,ACCESS_GROUP/CREATE,ACCOUNT/SET_TAGS_AT_OBJECT_CREATION,CONNECTOR/READ,API_CLASSIFICATION/READ,CDB/UPDATE,ENGINE/DELETE,MASKING_JOB_SET/READ,SOURCE/READ,ENGINE/READ

Monitor role

NONE
BOOKMARK/READ,SMTP_CONFIG/UPDATE,PRODUCT_INFO/READ,API_USAGE_REPORT/READ,JOB/READ,REPORT_SCHEDULE/CREATE,DSOURCE/READ,REPORT_SCHEDULE/READ,VDB_GROUP/READ,SMTP_CONFIG/VALIDATE,VCDB/READ,DSOURCE_CONSUMPTION_REPORT/READ,SOURCE/READ,DSOURCE_USAGE_REPORT/READ,CDB/READ,VDB/READ,REPORT_SCHEDULE/UPDATE,ENVIRONMENT/READ,SMTP_CONFIG/READ,ENGINE/READ,STORAGE_SUMMARY_REPORT/READ,REPORT_SCHEDULE/DELETE,VDB_INVENTORY_REPORT/READ

DevOps role

NONE
ENVIRONMENT/DELETE,ENVIRONMENT/CREATE,VDB/MANAGE_TAGS,VDB/START,BOOKMARK/SET_TAGS_AT_OBJECT_CREATION,VDB/UPDATE,VDB/DISABLE,DSOURCE/UPDATE,ENVIRONMENT/DISABLE,VDB_GROUP/DELETE,VDB_GROUP/REFRESH,BOOKMARK/READ,DATABASE_TEMPLATE/UPDATE,ENVIRONMENT/REFRESH,DATABASE_TEMPLATE/IMPORT,CDB/MANAGE_TAGS,DATABASE_TEMPLATE/UNDO_IMPORT,VDB/CREATE,VDB/ENABLE,SOURCE/MANAGE_TAGS,ENGINE/SET_TAGS_AT_OBJECT_CREATION,JOB/READ,BOOKMARK/UPDATE,DATABASE_TEMPLATE/READ,VCDB/UPDATE,VDB/SET_TAGS_AT_OBJECT_CREATION,VDB/PROVISION,VDB/SNAPSHOT,DSOURCE/MANAGE_TAGS,ENVIRONMENT/MANAGE_TAGS,DSOURCE/PROVISION,DSOURCE/REFRESH,DATABASE_TEMPLATE/DELETE,VDB/STOP,ENGINE/MANAGE_TAGS,VDB/REFRESH,BOOKMARK/CREATE,VDB_GROUP/UPDATE,BOOKMARK/DELETE,VDB_GROUP/MANAGE_TAGS,ENVIRONMENT/SET_TAGS_AT_OBJECT_CREATION,VDB/CREATE_VDBGROUP,VDB_GROUP/READ,DATABASE_TEMPLATE/CREATE,VDB_GROUP/SET_TAGS_AT_OBJECT_CREATION,VCDB/READ,CDB/READ,BOOKMARK/REFRESH_FROM_BOOKMARK,BOOKMARK/PROVISION_FROM_BOOKMARK,JOB/ABANDON,ENVIRONMENT/ENABLE,VCDB/MANAGE_TAGS,VDB/CREATE_BOOKMARK,BOOKMARK/MANAGE_TAGS,VDB/DELETE,ENVIRONMENT/UPDATE,PRODUCT_INFO/READ,DSOURCE/READ,VDB_GROUP/CREATE,CDB/UPDATE,SOURCE/READ,VDB/READ,ENVIRONMENT/READ,ENGINE/READ,SOURCE/UPDATE

Masking role

NONE
PRODUCT_INFO/READ,MASKING_JOB/DELETE,ENGINE/UPDATE,MASKING_JOB_SET/DELETE,JOB/READ,MASKING_JOB_SET/UPDATE,CONNECTOR/READ,ENGINE/DELETE,MASKING_JOB_SET/REMOVE_JOB,MASKING_JOB_SET/READ,CONNECTOR/UPDATE,MASKING_JOB/READ,JOB/ABANDON,MASKING_JOB_SET/COPY,ENGINE/READ,MASKING_JOB/UPDATE,CONNECTOR/EXECUTE,ENGINE/CREATE

Owner role

NONE
ENVIRONMENT/DELETE,DSOURCE/SNAPSHOT,VDB/START,MASKING_JOB_SET/SET_TAGS_AT_OBJECT_CREATION,BOOKMARK/SET_TAGS_AT_OBJECT_CREATION,VDB/UPDATE,MASKING_JOB_SET/REMOVE_JOB,VDB/DISABLE,DSOURCE/UPDATE,ENVIRONMENT/DISABLE,VDB_GROUP/DELETE,VAULT/READ,VDB_GROUP/REFRESH,BOOKMARK/READ,ACCOUNT/DELETE,DATABASE_TEMPLATE/UPDATE,ENVIRONMENT/REFRESH,DATABASE_TEMPLATE/IMPORT,DATABASE_TEMPLATE/UNDO_IMPORT,ACCESS_GROUP/DELETE,VDB/ENABLE,ENGINE/SET_TAGS_AT_OBJECT_CREATION,BOOKMARK/UPDATE,DATABASE_TEMPLATE/READ,VCDB/UPDATE,VDB/SET_TAGS_AT_OBJECT_CREATION,REPORT_SCHEDULE/READ,VDB/PROVISION,VDB/SNAPSHOT,REPORT_SCHEDULE/DELETE,DSOURCE/PROVISION,DSOURCE/REFRESH,DATABASE_TEMPLATE/DELETE,VDB/STOP,ACCOUNT/UPDATE,VDB/REFRESH,ACCOUNT/PASSWORD_RESET,ENGINE/UPDATE,MASKING_JOB_SET/DELETE,ACCESS_GROUP/READ,VDB_GROUP/UPDATE,ACCOUNT/READ,BOOKMARK/DELETE,ENVIRONMENT/SET_TAGS_AT_OBJECT_CREATION,VDB/CREATE_VDBGROUP,VDB_GROUP/READ,VDB_GROUP/SET_TAGS_AT_OBJECT_CREATION,VCDB/READ,MASKING_JOB/READ,CDB/READ,BOOKMARK/REFRESH_FROM_BOOKMARK,REPORT_SCHEDULE/UPDATE,BOOKMARK/PROVISION_FROM_BOOKMARK,ENVIRONMENT/ENABLE,VDB/CREATE_BOOKMARK,MASKING_JOB/UPDATE,ENGINE/CREATE_ENVIRONMENT,CONNECTOR/EXECUTE,ACCESS_GROUP/UPDATE,VDB/DELETE,ENVIRONMENT/UPDATE,VAULT/DELETE,MASKING_JOB/DELETE,ACCOUNT/SET_TAGS_AT_OBJECT_CREATION,MASKING_JOB_SET/UPDATE,DSOURCE/READ,CONNECTOR/READ,CDB/UPDATE,ENGINE/DELETE,MASKING_JOB_SET/READ,CONNECTOR/UPDATE,SOURCE/READ,VDB/READ,ENVIRONMENT/READ,ENGINE/READ,SOURCE/UPDATE

The subsequent DCT release will include the ability to create roles with custom sets of permissions.

Example configuration scenario

Access Groups can only be configured and updated via API as of DCT 4.0. Users will have the ability to perform these configuration steps within the DCT UI with the 5.0 release.

In this scenario, a DCT administrator will configure a new Access Group “App Team Alpha” who’s membership will include Accounts with the AD Group attribute CN=Alpha, CN=Teams, DC=delphix, DC=com as well as the manual addition of a unaffiliated user. This Access group will be “scoped” to have permissions from the DevOps role over all VDB’s with the {Team: Alpha} tag. 

Data assumptions

To create access group with above requirements, let first assume few values to understand the API call:

  • Access group name is App Team Alpha

  • DevOps role name =  "devops"

  • For AD users, one of the AD group attribute value is CN=Alpha, CN=Teams, DC=delphix, DC=com

  • Individual Account with account ID = 10

  • VDB with id = "1-VDB-DATASET-1"

  • Scope by object tag: {Team: Alpha}

Option one

Create an access group with all required roles and permissions as mentioned above in a single API call.

API: POST -  https://<hostname>/v2/access-groups

Request Body:

NONE
{
    "name": "Team Alpha",
    "account_ids": [
        10 
    ],
    "account_tags": [ 
        {
            "key": "login_groups",
            "value": "CN=Alpha, CN=Teams, DC=delphix, DC=com"
        }
    ],
    "policies": [
        {
            "role_id": "devops",
            "everything": false,
            "object_tags": [
                {
                    "key": "Team",
                    "value": "Alpha"
                }
            ],
            "objects": [
                {
                    "object_id": "1-VDB-DATASET-1",
                    "object_type": "VDB"
                }
            ]
        }
    ]
}

Response: 201 - Created

Option two

Create the access group for above mentioned data/requirements by using different API calls as well. Do this using multiple APIs.

  1. Create Access Groups

API: POST - https://<hostname>/v2/access-groups

Request Body:

NONE
{
    "name": "Team Alpha"
}

Response: 201 - Created

The Access Group id will appear in the response, as shown:

NONE
{
    "id": "111111-2222-aaaa-bbbb-123456abcdef",
    "name": "Team Alpha",
    "single_account": false
}

2. Add account manually

API: POST - https://<hostname>/v2/access-groups/111111-2222-aaaa-bbbb-123456abcdef/account-ids

Request Body:

NONE
{
  "account_ids": [
    10
  ]
}

Response: 200 - OK (Updated Access Group)

3. Add AD users automatically for the groups assumed above.

In order to add AD users automatically to this Access Group, we will need to create account tags matching with AD groups as follows:

API: POST - https://<hostname>/v2/access-groups/111111-2222-aaaa-bbbb-123456abcdef/tags

Request Body:

NONE
{
    "tags": [
        {
            "key": "login_groups",
            "value": "CN=Alpha, CN=Teams, DC=delphix, DC=com"
        }
    ]
}

Response: 200 - OK (Updated Access Groups)

4. Assign DevOps role to the Access Group.

For adding DevOps role, we will create a policy/scope for the access group as follows:

API: POST - https://<hostname>/v2/access-groups/111111-2222-aaaa-bbbb-123456abcdef/policies

Request Body:

NONE
    "policies": [
        {
            "role_id": "devops",
            "everything": false
        }
    ]
}

Response: 200 - OK (Updated Access Groups)

5. Add tags to Scope/Policy of the Access Group.

Assume the created policyId/scopeId is 99999-2222-aaaa-bbbb-abced92dk3.

API: POST - https://<hostname>/v2/access-groups/111111-2222-aaaa-bbbb-123456abcdef/policies/99999-2222-aaaa-bbbb-abced92dk3/object-tags

Request Body:

NONE
{
    "tags": [
        {
            "key": "Team",
            "value": "Alpha"
        }
    ]
}

Response: 200 - OK

6. Add VDB manually.

To add VDB manually, use the below API:

API: POST - https://<hostname>/v2/access-groups/111111-2222-aaaa-bbbb-123456abcdef/policies/99999-2222-aaaa-bbbb-abced92dk3/objects

Request Body:

NONE
{
    "objects": [
        {
            "object_id": "1-VDB-DATASET-1",
            "object_type": "VDB"
        }
    ]
}

Response: 200 - OK

User interface

Copy role scope

On the detail page of a role scope, an action is now available to copy it. The default name of the copied scape is "Copy of [name of the original scope]", which can later be updated with the edit scope wizard. The list of scopes are sorted by name, allowing for easy access in locating the created copy. To create a scope for a brand new role that is not yet added to the Access Group, you must first add the role by editing the role tile on the left side of the scope detail page.

Delete role scope

On the detail page of a role scope, an action is now available to delete it. The delete button is unavailable if the role scope is the only one of that role. If the scope should still be deleted and the button is unavailable, you must use the edit role wizard to remove the role entirely, ultimately deleting the role scope.

Advanced scope type

API Example:

NONE
curl --location --request POST '<hostname>/v3/access-groups/{access-group-id}/scopes/{scopeId}/objects' \ 
--header 'Content-Type: application/json' \
--data-raw '{
    "objects": [
        {
            "object_id": "1",
            "object_type": "ACCOUNT",
            "permission" : "READ"
        }
    ]
}'

Add an always allowed object to Access Group scope
Always allowed objects can be defined as objects that are always allowed for an access group scope. This can be set as follows:

Add always allowed objects:

NONE
curl --location --request POST '<hostname>/v3/access-groups/{access-group-id}/scopes/{scope-id}/always_allowed_permissions' \--header 'Content-Type: application/json' \
--data-raw '{
    "always_allowed_permissions": [
        {
            "object_type": "ACCOUNT",
            "permission" : "READ"
        }
    ]
}'
Response: The updated access group scope

Here it means that all objects with object type ACCOUNT and permission READ are allowed with this access group scope. This will clear out matching object type and permissions, if any in objects attribute of access group scope.

Remove always allowed objects:

NONE
curl --location --request POST '<hostname>/v3/access-groups/{access-group-id}/scopes/{scope-id}/always_allowed_permissions/delete' \--header 'Content-Type: application/json' \
--data-raw '{
    "always_allowed_permissions": [
        {
            "object_type": "ACCOUNT",
            "permission" : "READ"
        }
    ]
}'
Response: The updated access group scope
JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.