Permission Management

General

The built-in permission management of XDM allows you to control access to objects on a per-user or per-role basis. More specifically, you can control:

  • Which objects (such as tasks) can be accessed

  • Which parts of the XDM user interface are displayed

  • Which actions (such as executing or deleting a task) can be performed

You can use permissions to model different usage scenarios for XDM. For example, you can classify the end users of XDM into three different groups with the following permissions:

  • Administrative users can see all objects

  • Modelers have read-only access to some infrastructure objects (connections, storage locations, etc.), and can create application models, tasks that use these objects and models, and data shops

  • All other users are only allowed to trigger task executions from the data shop

Users and roles

A user is an individual person identified by his or her name. The user is authenticated by a password. Roles can be used to group multiple users together. A user can belong to zero, one, or multiple roles. A role is identified by its name.

Users and roles can be retrieved from an LDAP server. In this case, XDM authenticates each login attempt against the LDAP server and retrieves the user information and list of roles from the server.

It is also possible to configure the users and roles in an XDM configuration file.

For more information on how to connect to an LDAP server or store users in a configuration file, refer to section User Management.

Global administration role

The global administration role is a special role within XDM. All users with this role have the READ privilege for all lists and objects, and the ADMINISTRATION privilege for every permission list. The default name for the global administrative role is ADMIN. You can change the name of the global administrative role as described in section configuration.

Purchaser role

The purchaser role is a role to identify the data shop users. Users that are a member of this role get a customized UI that better supports the needs and workflow of data shop users. Technical details are not visible to data shop users, instead they work with their application specific terminology and can order test data from an end-user perspective. You can change the name of the purchaser role as described in section data shop purchaser role.

Privileges and permissions

A privilege is a specific action, such as deleting an existing task, that can either be allowed or disallowed.

A permission is a combination of a set of privileges and the name of a user or a role that this set of privileges applies to.

Permissions are assigned either to individual objects or to lists of objects. A user is allowed to perform a certain action on an object if the user or any of the roles of which the user is a member holds a permission which includes the privilege to perform that action.

The following privileges exist:

Privilege Description

READ

Allows users to see objects in lists, to see details about objects, and to request a data shop order.

WRITE

Allows users to modify attributes of an object.

DELETE

Allows users to delete an object.

CREATE

Allows users to create new objects in a list.

EXECUTE

Allows users to execute or schedule a task or workflow template, and to place a data shop order.

ADMINISTRATION

Allows users to grant permissions for an object to other users.

SOURCE USAGE

Allows an environment or a connection to be used as the source of a task.

TARGET USAGE

Allows an environment or a connection to be used as the target of a task.

BROWSE

For connections only. Allows users to see the contents of tables in the schema browser, and in the output of XDM tasks that provide a data preview.

APPLY SQL

For connections only. Allows users to execute SQL statements for tables in the schema browser, and in the output of XDM tasks that provide a data preview.

DIAGNOSE

For task templates, tasks, workflow templates and workflows only. Allows users to see diagnostic data like stage outputs or batch reports.

SCRIPT

For credentials only. Allows the usage of this credential in a task stage hook.

MODIFY DATA

For data reservation only. Allows modification of a data reservation.
READ privilege is implied by all other privileges. For example, if a user has a permission for an object that only contains the EXECUTE privilege, then this user implicitly also has the READ privilege for this object. This is required so that users can see the objects on which they are allowed to act upon.

When creating a new object, the current user automatically becomes its owner. The owner of an object always has exactly one permission for the object. This permission always contains the ADMINISTRATION privilege and, initially, also all other privileges. It is not possible to create additional permissions on an object for the user that is already its owner. However, it is possible to grant and revoke privileges on the existing permission (except for the ADMINISTRATION and READ privileges, which cannot be revoked for the owner).

XDM checks permissions every time an object is accessed. If a user does not have the READ privilege (explicitly or implicitly) on an object, then the object is not visible inside the XDM user interface for this user. Also, user interface buttons or context menu entries may be missing if the user does not have the privilege to perform a certain action on an object.

Permission attributes

Each object that supports permission management has a list of permissions that can be accessed via the permission list. A permission has the following attributes:

Grantee

The grantee is the name of the user or role that the permission is granted to.

Grantee type

Specifies the type of the grantee. Possible values are:

  • OWNER The permission that belongs to the owner of an object. The OWNER type is set by XDM and cannot be specified manually.

  • USER The permission belongs to a specific user.

  • ROLE The permission is associated with a role and applies to all users that belong to this role.

Read

Specifies that the grantee has read permission on the object. The grantee is able to see the object in lists and can see all details of the object. In addition, the grantee can reference this object (for example, a user that has the READ privilege on a credential object can refer to this credential object when creating a new database connection).

Write

Specifies that the grantee has the permission to change the settings and attributes of an object. This also includes modifying any rule lists that might be associated with the object (for example, the selection rules of a task template).

Delete

Specifies that the grantee can delete the object.

Create

Specifies that the grantee can create new objects in a list.

Execute

Specifies that the grantee may execute the object, or schedule the object for later execution. This permission only applies to objects that are executable, i.e. tasks, task templates, workflow templates, and data shop orders.

Administration

Specifies that the grantee can grant and revoke permissions to and from other users. A user that creates an object automatically receives the ADMINISTRATION permission on the object.

Source usage

Specifies that the object can be used as the source for an XDM task. This permission only applies to environments and connections. If a user does not have the SOURCE_USAGE privilege for an environment or connection, it is not displayed in a drop down list where the source environment or connection for a task needs to be selected.

Target usage

Specifies that the object can be used as the target for an XDM task. This permission only applies to environments and connections. If a user does not have the TARGET_USAGE privilege for an environment or connection, it is not displayed in a drop down list where the target environment or connection for a task needs to be selected.

Browse

Specifies that the grantee is allowed to see the contents of database tables when using the schema browser, and when inspecting the output of an XDM task that provides a data preview. This permission only applies to connections.

In addition to the BROWSE privilege in XDM, it is also a requirement that the database user have SELECT authorization for tables whose contents should be displayed. The database user is defined in the credential object that is associated with a database connection. The SELECT authorization is granted and revoked by the database system, not inside XDM.
Modify data

Permits the grantee to modify a data reservation entity and the reserved table rows.

Objects and object lists

XDM differentiates between objects and object lists. Object lists are used whenever an object can have multiple dependent objects of the same type. For example, after creating a task template, you can create an arbitrary number of tasks that are based on that template. These tasks are not independent of the task template; they inherit settings from the template and cannot exist without it.

In this example, the task template and each of the tasks are individual objects, but the task template has a list of tasks that is used to keep track of all tasks that are derived from it. In order to create a new task based on the task template, a user must have the WRITE privilege on the task template. On the other hand the CREATE privilege is required on the task template list to create new task templates.

Rules, such as selection rules, exclude rules, mapping rules, etc., are not considered individual objects, and the rule lists in which they are stored are not considered object lists that can have their own sets of permissions. It is sufficient, for example, to have the WRITE privilege on a task template in order to add, modify, or delete the selection rules that are associated with that template.

Inheritance of permissions

Permissions granted on an object are automatically inherited by dependent objects. For example, if a user has the EXECUTE privilege on a task template, then this user implicitly has the EXECUTE privilege on all tasks that are derived from that task template. If a user does not have the EXECUTE privilege on a task template, then the EXECUTE privilege on individual derived tasks can still be granted to that user.

Default permissions

You can configure a set of global default permissions. A default permission has the following attributes:

Grantor

Specifies that this default permission is to be applied to objects that are created by this user or, if the grantor is a role, by any member of this role.

Grantee

Identifies the user or role for whom the permission is to be granted.

A set of privileges

Identifies which privileges are to be assigned to the grantee. This can be any subset of the privileges listed under Privileges and permissions.

A set of object types

Identifies the types of newly created objects to which the default permission applies.

Whenever a user creates new objects, XDM automatically applies the default permissions that meet the following conditions:

  • The grantor of the default permission is equal to the username or one of the roles that the user is a member of.

  • One of the object types that are specified in the default permission matches the type of object that has been created.

It is possible to have distinct default permissions for different grantees (users and roles). You can activate or deactivate the default permissions for individual object types as needed.

If multiple permissions with the same grantee and grantee type are applied to objects, these permissions will be merged with each other.

System-wide default permissions

To configure system-wide default permissions, go to System Settings → Permission Recipient → choose a grantor → Default Permissions. By default, only admin users can access the permission recipient list. More information about default permissions can be found in the reference.

User-specific default permissions

In addition to system-wide default permissions, each user can have a set of user-specific default permissions. They provide the same functionality, but are defined individually by each user.

In user-specific default permissions, the grantor is always the username of the user who created them as the default permission. This cannot be changed.

To configure your user-specific default permissions, go to User Settings → Settings → Configure user default access permissions. More information about user default permissions can be found in the reference.

If multiple permissions with the same grantee and grantee type are applied to objects, these permissions will be merged with each other.

Applying default permissions to existing objects

You can use the Apply action to apply the set of default permissions to all objects that the grantors of the permissions have already created. This updates all permissions that currently exist on all objects in one of two possible ways, depending on which mode (either merge or replace) is used for the apply process:

Merge

The merge option merges the privileges of existing permissions for the combination of grantee and grantee type. The resulting permission object contains all privileges that the grantee held previously, and all privileges that are part of your default permission for that grantee.

Replace

The replace option overwrites the privileges of existing permissions for the combination of grantee and grantee type. The resulting permission object only contains your default privileges. All privileges that the grantee held previously but are not part of your default permission are revoked. This option is useful if you removed privileges on a default permission, and you want to revoke these privileges on the corresponding permissions that exist on your objects as well.

Applying default permissions also creates new permissions on each existing object for those grantees that currently do not have any permissions on the object.

List access permissions

List access permissions are used to set global permissions on the different object lists that exist at the top level of the object hierarchy within XDM (for example, the list of database connections). These lists are pre-defined. You can neither add nor remove lists at the top level. You can, however, add and remove permissions on these lists.

To configure list access permissions, go to System Settings → Permission recipient → List permission. By default, only admin users can access the list access permissions.

Execution permission

In order to execute tasks and workflow templates, and to place data shops, different privileges are necessary.

Executing a task

To start a task execution, the following privileges are required:

  • EXECUTE privilege on the task

  • SOURCE_USAGE and/or TARGET_USAGE privilege on the referenced connections (for tasks that have references to connections, such as table copy tasks)

  • SOURCE_USAGE and/or TARGET_USAGE privilege on the referenced environments (for tasks that have references to environments, such as row level processor tasks)

  • READ privilege on the following objects:

    • The task template that the task is based on

    • The storage locations that are associated with the connections

    • The credentials that are used in the connections and storage locations

    • The application model and application model version that is associated with the environment

    • Any modification set that is used by the task, task template, connection, environment, application model, or application model version

    • Any modification method that is used by any of the involved modification sets

    • Any custom parameter that is used in the task template

    • Any file object that is referenced by the task template

For some task types, additional permissions are required. These are described in the Required permissions section of the respective task descriptions.

Executing a task template

When executing a task template through an automatically generated task (for example, when using a workflow template, placing a data shop order or executing a task via the Jenkins plugin), the following privileges are required:

  • EXECUTE privilege on the task template

  • CREATE privilege on the task template’s list of tasks

  • All permissions listed above to execute the resulting task

Executing a workflow

When starting a workflow, the following privileges are required:

  • EXECUTE privilege on the workflow

  • READ privilege on

    • the workflow template

    • any custom parameter used in the workflow template

  • All required privileges for executing the individual tasks in the workflow

Executing a workflow template

When starting a workflow template, the following privileges are required:

  • EXECUTE privilege on the workflow template

  • READ privilege on any custom parameter used in the workflow template

  • All required privileges for executing the individual tasks in the workflow

Placing or requesting a data shop order

When a data shop order is placed, a new task based on the data shops task template is created and executed (either immediately, or at a specified point in time). The following privileges are required to place a data shop order:

  • EXECUTE privilege on the data shop

Instead of placing a data shop order, it is also possible to request an order. A user with appropriate authorization can then review and approve the request. The order itself can then be executed immediately upon approval, or at a specified point in time. To request a data shop, the following privileges are required:

  • READ privilege on the data shop

Since data shops are based on task or workflow templates, it is possible that additional information has to be provided in order to execute the implicitly created task, or to request its execution. If the data shop requires the specification of one or more connections or environments, the following additional privileges are required:

  • READ permission on the connection or environment list

  • READ privilege on the involved connections or environments

The data shop itself may or may not be associated with a credential object. This credential object must identify a valid XDM user.

If the data shop is associated with a credential object, the user specified in this credential object needs to have all privileges described under executing a task template for a successful execution of the task. If the data shop is not associated with a credential object, the user that places or requests the data shop needs to hold these privileges.

Permission administration

A permission recipient is a user or role which is identified by its name and can grant privileges on owned or administrated objects to other permission recipients. Thus, a permission always has a grantor which grants privileges to a grantee. Under System Settings → Permission recipient administrators can see all available permission recipient, and also they can grant access to this list to others. On an individual permission recipient administrators can manage the global list access of this recipient. Further, the default permissions can be administrated and a list of received default permissions can be seen. Lastly, all objects on which this recipient has at least one privilege can be seen.

There are several administration actions that can be applied on a permission recipient. The most useful functions are the permission transfer and the recipient export. With the permission transfer the owner of all owned objects can be changed to another permission recipient. The export of a permission recipient enables administrators to transfer a user or role and their default permissions to another XDM environment. Details to this functionality can be found in the reference article on permission recipient.

Additional considerations

The following guidelines can help you configure XDM permissions for different usage scenarios.

Giving full access for all users

If you want to give all XDM users full access to all objects, you can either share the administrative account that is pre-configured after the installation, or you can create individual user accounts and add all users to the global administrative role.

The default user ID for the administrative account is admin. If you share this account among all users of XDM, then all objects within XDM are created by the same user ID and as a consequence, all users of XDM can see, create, modify and delete all objects as well as execute all tasks.

If you use individual user accounts instead, but still want full access for all users, you need to configure the users as follows:

  • All users must be a member of the global administrative role (the default name of this role is ADMIN).

  • All users must configure their user default permissions so that the READ, WRITE, EXECUTE, SOURCE_USAGE, and TARGET_USAGE privileges are assigned to the global administrative role.

You can use the Apply action in order to assign the user default permissions to all objects that already exist.

Switching from internal user management to LDAP

During an evaluation phase of XDM, you may not want or not be able to use LDAP for a central management of users and roles. As a result, during this phase it is common to use XDM exclusively as the administrative user. While this is possible, doing so means that all objects that are created within XDM belong to the administrative user and have no default permissions for other users.

To avoid this situation, you can use XDM’s internal user management and define the users with the same usernames that are used in your LDAP server. This allows for a seamless switchover from internal user management to LDAP user management later. For more details on the internal user management, refer to section internal user management in the configuration chapter.

The section Examples for role management provides examples, how a central management can be configured.

Impact of changing licensed options

When reducing the licensed options in XDM, the usability of existing unlicensed objects becomes limited. Existing objects that belong to now unlicensed components are still readable and removable. Other permissions will have been removed so that these objects can no longer be created, executed or imported. Administrators can see all components, regardless whether they are licensed or not. Therefore, an administrator sees all the different object lists that exist at the top level of the object hierarchy. However, unprivileged users can only see licensed entries for which he/she has the required list access permissions.

For example, suppose you have removed the license option for using Oracle databases and there is an existing table copy template that uses a connection to an Oracle database. This template will still be readable but the tasks of that template can no longer be executed. If you change the connection to a licensed one, then all tasks will again be executable. If the connection will not be used again, then it can be deleted by an administrative user. Administrators can see unlicensed components in XDM, and therefore they can access the list of connections to Oracle databases. From that list it is possible to delete existing unused connections.