Users and Groups

A major benefit of the central nature of the Data Control Tower architecture is the ability to deliver unique experiences that greatly expand customer abilities to work at scale with a large Delphix deployment. Users and groups is a cluster of several enhancements aimed at streamlining the administration of user access over a Delphix deployment. No longer will user access to virtualization and masking objects be governed by engine-based policies. Instead, this task is shifted to a hub and spoke model governed by Data Control Tower under the Users and Groups tab. Data Control Tower admins are now able to create groups that can span multiple engines with granular policy control, which is optionally tied to enterprise access standards like Active Directory or LDAP. Users and groups on Data Control Tower fall under the following categories:

Enabling Users and Groups: What to Expect

Usernames must start with a letter and contain only alphanumeric characters, hyphens, underscores, and/or periods.

Many customers will already have long-established user groups governing access and permissions on objects in both Virtualization and Masking Engines. Data Control Tower will not disrupt those existing group-based structures. Instead, once all internal preparations are made for switching to the Data Control Tower-based access model, a Data Control Tower admin opts an engine into the new model via the infrastructure screen, and DCT will import those existing structures as import groups (Virtualization and Masking Engines will have their own import groups). From there, new groups can be created with the new global model in practice. To enable Data Control Tower Users and Groups, a Data Control Tower Admin must select the Enable Users and Groups option to the side of a specific engine on the Infrastructure page.



Engine Opt-In: must be done on the infrastructure screen under the specific engine.

When the feature is enabled for a connected engine, the following things happen:

  1. All users on the engine with a valid email address are added as Users in Data Control Tower. 
  2. An Access Group named <username.import.group> will be created for each user (if an import group exists from a previous engine import, the system will use this instead of creating a new one). We will recreate this user’s current permissions in this group, providing uninterrupted access for all engine-defined users. We expect these initial imported Access Groups to provide a model as you create purpose-built groups with multiple users to meet your access needs. Note: users with legacy API (password-based authentication to the engine API or CLI)  access using name/password will retain this access. Future API access should be configured using API Keys
  3. All user accounts on an engine without a valid email address are added as Service Accounts in Data Control Tower. These are maintained as there are some customers that have used usernames and passwords to facilitate API access. Access should be facilitated via API keys, but there may be a period for which the old model is still required. Service accounts will maintain their current permissions on this specific engine (the permissions for these service accounts will be editable from Data Control Tower).

    Service accounts exist outside of the access groups model, which is how Data Control Tower manages User permissions. If any permissions for a service account needs modification, this can be done on a per-service account level. 
  4. A single Admin Group is created for the engine, and any users with Delphix Admin permissions will be added to this group.


Changes made in users and groups will have an immediate visual update via the Data Control Tower UI. However, those same changes will take up to 30 seconds to propagate to engines impacted by those changes due to the communication cadence between Data Control Tower and connected engines. During this time, the modifications made in Data Control Tower will cause the changed users and datasets to be flagged as “adding” or “deleting”. If an engine is offline, the propagation of changes to the engine will not work.

Virtualization Access Groups

This tab within the Users and Groups page dictates object access and permissions associated with those objects. To create a new group:

  1. Click the Add Group button and provide a group name and description as prompted.
  2. The next screen has two tabs: Users and Data.
    1. IdP mapping is dynamic and relies on an identified attribute sourced from your IdP, common example attributes may be group or team identifiers. Once an attribute is added (there is no limit to the number of attributes in a group) the list of users with that attribute is dynamically populated. See the IdP Attribute for instructions on how to set this up.
    2. Add User will open a searchable list of users who are recognized with your IdP and have either logged into Data Control Tower or already have an account on a connected engine.
    3. Note: If a user is not on the list populated by clicking on Add User, they must authenticate to Data Control Tower from their IdP once. This will create the user record and they will then show up on the Add User list from there on out.
    1. Users Tab: There are two ways to add users to an access group. These are not mutually exclusive: Identity Provider (IdP_ Attribute Mapping and manual Add User
  3. Once all users have been added to the group, the next step is to add data objects (dSources and VDBs) that the group members can access. By clicking the data tab a list of all the objects (dSources and VDBs) contained within connected Virtualization engines will be listed.
  4. Once the right collection of data objects have been added, the next step in the add data wizard is to assign privileges to those objects. Data Control Tower follows the same object permission scheme as Virtualization.
  5. Once permissions have been set, your virtualization access group is complete.


          Virtualization User Groups: User Tab with a combination of IdP Mapped and Manually added Users. 


          

           Virtualization User Groups: Data Tab with a mixture of data objects spread across multiple Engines with granular permissions.

Masking Access Groups

User and role management on Delphix Masking is based on defining custom roles made up of granular permissions attributed to a user. This role is then associated with specific environments on the engine. This differs from Delphix Virtualization where a user is given a “standard” role and permissions (owner, operator, provisioner, and data reader) are defined by an object (dSource or VDB). In order to bridge the gap between user and object-centric permission models, Users and Groups in Data Control Tower introduces a new permission object for Delphix Masking - the permission set. 

The masking permission set involves three defined items: engine, environments on that engine, and roles.

Any number of permission sets can be included in a masking access group. In the case where multiple permission sets reference the same engine, DCT will create multiple user profiles with the same user email to define the custom role and environment combination.

Masking Access Groups have a similar user interface experience to Virtualization Access Groups with the difference being that access is defined by masking permission sets (engine, environment, and role combinations), rather than specific objects like dSources and VDBs. 

The Masking tab within the users and groups page dictates object access and permissions associated with those objects. To create a new group:

  1. Click the Add Group button and provide a group name and description as prompted.
  2. The next screen has two tabs: Users and Permission Sets.
    1. Users Tab - there are two ways to add users to an access group. These are NOT mutually exclusive: IdP Attribute Mapping and Manual Add User
      1. IdP mapping is dynamic and relies on an identified attribute sourced from your IdP, common attributes would be a group or team identifiers. Once an attribute is added (there is no limit to the number of attributes in a group) the list of users with that attribute is dynamically populated. See the IdP Attribute Mappings for instructions on how to set this up.
      2. Add User will open a searchable list of users who are registered with your IdP and have either logged into Data Control Tower or are granted access to a connected engine.
  3. Once all users have been added to the group, the next step is to add masking objects (permission sets) that the group members can access. Clicking the Permission Sets tab will bring up the list of attributed permission sets.

  4. Clicking Add Permission Set will bring up a wizard to add the engine, role, and then environment combination that make up each permission set (Note: a role must be pre-defined on the engine in order for DCT to use it with permission sets).

    From the permissions set wizard, applicable engines must be selected first.

    The next step in the wizard is to add relevant roles (these are defined on the engine first and imported into DCT).

    The final step in the wizard is to add applicable environments.

  5. Once permissions have been set, your masking access group is complete. 

Delphix recommends all Masking Engines opted into DCT Users and Groups upgrade to 6.0.7 as soon as it is available. In Masking Engine versions prior to 6.0.7.0, there is no user operation lockdown. Thus, opting into this feature assumes that Delphix administrators will avoid any sort of “on engine” modifications to user's permissions and will use DCT to set all permissions and object access.

Self-Service Access Groups

A common use case among Delphix administrators using the legacy Users and Groups model is to have group-based access accounts for Self-Service use. This was accomplished by sharing a username and password among multiple users in order to provide ease of administration as groups of Self-Service users moved from project-to-project and, as a result, needed access to different containers. Our recommendation is to stop the use of these bulk user access groups and, instead, 1) ensure each self-service user is registered with your IdP with an associated email and 2) assigned to Self-Service User Groups. The new construct in Data Control Tower is meant to replace this practice of batch user access groups.
This feature is purely aimed at easing the administration of Self-Service User Groups. The Self-Service end user will continue to access the Self-Service interface, the only difference is that specific container access will be dictated by the Delphix Admin in Data Control Tower.

Self-Service user groups have a similar experience as with Virtualization Access Groups with the difference being that access is defined by Pre-configured Containers, rather than specific objects like dSources and VDBs. 

This tab within the Users and Groups page dictates object access and permissions associated with those objects. To create a new group:

  1. Click the Add Group button and provide a group name and description as prompted.
  2. The next screen will have two tabs: Users and Data.
    1. IdP mapping is dynamic and relies on an identified attribute sourced from your IdP, common attributes would be group or team identifiers. Once an attribute is added (there is no limit to the number of attributes in a group) the list of users with that attribute is dynamically populated. See the IdP Attribute for instructions on how to set this up.
    2. Add User will open a searchable list of users who are registered with your IdP and have either logged into Data Control Tower or are granted access to a connected engine.
    1. Users Tab - there are ways to add users to an access group that is NOT mutually exclusive: IdP Attribute Mapping and Manual Add User
  3. Once all users have been added to the group, the next step is to add Self Service Container Access.

          Self Service User Groups: User Tab with a combination of IdP Mapped and Manually added Users. 
          

           Self Service User Groups: Data Tab with a mixture of Self Service Containers spread across multiple Engines.

Engine Admin Access Groups

Engine Admin Groups remains one area that is engine specific once an engine has opted into Users and Groups. The reason for this is to prevent privilege creep that can arise from multiple admin groups governing admin access to an engine. Once an engine has opted into users and groups, an engine admin import group will be created under the Admin tab in users and groups. From there, the experience of adding manual users or IdP attributed users remains the same as with the rest of the users and groups experience. Read below for greater detail:

  1. When an engine is opted into Data Control Tower users and groups, the existing admins are imported into an Engine’s Admin Access Group found under the Admin tab on the Users and Groups page in Data Control Tower.  
  2. When an engine group is established, a Data Control Tower Admin can add users to that import group using the following methods: IdP Attribute Mapping and Manual Add User
    1. IdP mapping is dynamic and relies on an identified attribute sourced from your IdP, common attributes would be group or team identifiers. Once an attribute is added (there is no limit to the number of attributes in a group) the list of users with that attribute is dynamically populated. See the IdP Attribute for instructions on how to set this up.
    2. Add User will open a searchable list of users who are registered with your IdP and have either logged into Data Control Tower or are granted access to a connected engine.
  3. Once a user is added to the admin user group, the specific user will now have the ability to access the specific engine and will have administrator rights.

IdP Attribute Mapping Setup and Configuration

IdP attribute mapping marks a major improvement for Delphix Administration in that group membership can now be driven by enterprise directory services such as Active Directory or LDAP directories that are tied to an enterprise IdP. This section will go over general principles of the IdP mapping implementation including a detailed example with Okta (a common IdP vendor). However, note that IdP mapping is custom to each customer’s IdP vendor of choice and includes nuances custom to each Delphix customer. Your IdP admin can map the existing or newly created attribute, such as Group or Team, to dlpx_attrs in the Delphix assertion (outgoing claim) so that the attribute is automatically included for configuration in DCT Users and Groups.

As mentioned throughout the Users and Groups documentation - IdP mapping provides a highly scalable alternative to manual user administration. To accomplish this, Data Control Tower will associate assigned IdP attributes with specific User Groups so that Enterprise systems, such as Active Directory or LDAP services can dynamically dictate Delphix User Group membership.

Case Study: Using your Enterprise Active Directory to Determine Group Membership

In this case study, we will focus on the ease of administration that comes with mapping Active Directory (AD) - defined groups to IdP attributes, which can be tied to user groups within Data Control Tower. For this case we have two App Development Groups as shown below:



Each team member’s team membership is registered under the “Team” Active Directory attribute. The Team attribute must be mapped to the external assertion to drive group membership in Data Control Tower, this is known as a Transform Claim Rule in Active Directory. The IdP admin would create a new rule in the Delphix IdP configuration to transform "Team", then mapping into dlpx_attrs.

Once the mapping is configured, in the above example, there would be two IdP mapping options available in the “add users” page - App A and App B. In the case of a Data Control Tower Virtualization user group “App Dev Team A”, the “App A” attribute is assigned. From there, Alberto and Anne-Marie are automatically added to that group.

Now, in the case where Anne-Marie rotates groups with Ross, who is originally a member of App B. This change would first be reflected in Active Directory. From there, the customer IdP would pick up the change and register it within its “dlpx_attrs” attribute. Next, Data Control Tower is constantly looking for updates from connected IdPs. Data Control Tower would quickly sense the change and propagate it automatically - Anne-Marie would be in the Data Control Tower “App Dev Team B” group and Ross would be in the “App Dev Team A” group.