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
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
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
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
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
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:
{
"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.
Create Access Groups
API: POST - https://<hostname>/v2/access-groups
Request Body:
{
"name": "Team Alpha"
}
Response: 201 - Created
The Access Group id will appear in the response, as shown:
{
"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:
{
"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:
{
"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:
"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:
{
"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:
{
"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:
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:
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:
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