Roles and permissions

Deploy includes a fine-grained access control scheme to ensure the security of your middleware and deployments. The security scheme is based on the concepts of principals, roles, and permissions.

Principals

A security principal is an entity that can be authenticated in Deploy. Out of the box, Deploy only supports users as principals; users are authenticated by means of a username and password. When using an LDAP repository, users and groups in LDAP are also treated as principals. For more information about using LDAP, refer to How to connect to your LDAP or Active Directory.

Deploy includes a built-in user called admin. This user is granted all global and local permissions.

Note: In Deploy, user principals are not case-sensitive.

Roles

Roles are groups of principals that have specific permissions in Deploy. Roles are typically identified by a name that indicates the role the principals have within the organization; for example, deployers. In Deploy, permissions can only be granted to, or revoked from, a role.

When permissions are granted, all principals that have the role are allowed to perform some action or access repository entities. You can also revoke granted permissions to prevent the action in the future.

Permissions

Permissions are rights in Deploy. Permissions control the actions a user can execute in Deploy, as well as which parts of the repository the user can see and change. Deploy supports global and local permissions.

Global permissions

Global permissions apply to Deploy and all of its repository. In cases where there is a local version and a global version of a permission, the global permission takes precedence over the local permission.

Deploy supports the following global permissions:

Permission	Description
admin	All rights within Deploy.
controltask#execute	The right to execute control tasks on configuration items.
discovery	The right to perform discovery of middleware.
login	The right to log into the Deploy application. This permission does not automatically allow the user access to nodes in the repository.
report#view	The right to see all reports. When granted, the UI will show the Reports tab. To be able to view the full details of an archived task, a user needs read permissions on both the environment and application.
security#edit	The right to administer principals, roles, and permissions.
security#view	The right to view user management information.
task#assign	The right to assign a task to another user.
task#move_step	This permission has no effect.
task#preview_step	The right to inspect scripts that will be executed for steps in an execution plan.
task#skip_step	The right to skip a step in an execution plan.
task#takeover	The right to assign a task to yourself.
task#view	The right to view all the tasks. With this permission, you can view but not modify other tasks in the system.

Important: The task#view permission depends on the local permissions that apply to environments. To view tasks that are assigned to other users, you must have the read permission on the environment where the task was created. You must also have local environment permissions such as:

• deploy#initial permission to view all tasks of the type Initial
• deploy#undeploy permission to view all tasks of the type Undeploy
• deploy#upgrade permission to view all tasks of the type Upgrade

Caution: The security#edit permission lets you manage user accounts (including Admin user accounts) and roles in Deploy. Exercise caution while assigning this permission to non-admin roles as users assigned with a role that has the security#edit permission can edit other Admin user accounts and roles too.

Local permissions

In Deploy, you can set local security permissions on repository nodes (such as Applications or Environments) and on directories in the repository. In cases where there is a local version and a global version of a permission, the global permission takes precedence over the local permission.

Deploy supports the following local permissions:

Permission	Description	Applies to…
controltask#execute	The right to execute control tasks on configuration items.	Applications, Environments, Infrastructure, and Configuration
generate#dsl	The right to generate the contents of a directory as a Groovy file.	Applications, Environments, Infrastructure, and Configuration
deploy#initial	The right to perform the specification, delta analysis, orchestration, and planning (but not execution) phases of the initial deployment of an application to an environment. See Deployment Phases for more information.	Environments
deploy#undeploy	The right to undeploy an application from an environment.	Environments
deploy#upgrade	The right to perform an update deployment phases up to the planning phase(not including the execution phase) of an application to an environment. Note that this permission does not allow the user to deploy deployables in the package to new targets. See Deployment Phases for more information.	Environments
import#initial	The right to import a package for an application that does not exist in the repository.	Applications
import#remove	The right to remove an application or package.	Applications
import#upgrade	The right to import a package for an application that already exists in the repository.	Applications
read	The right to see CIs in the repository.	Applications, Environments, Infrastructure, and Configuration
deploy_admin_read_only	This right will give read only permission.	Applications, Environments, Infrastructure, and Configuration
repo#edit	The right to create and modify CIs in the repository.	Applications, Environments, Infrastructure, and Configuration
task#move_step	This permission has no effect.	Environments
task#skip_step	The right to skip a step in an execution plan.	Environments
task#takeover	The right to assign a task to yourself.	Environments

How local permissions work in the hierarchy

In the hierarchy of the Deploy repository, the permissions configured on a lower level of the hierarchy overwrite all permissions from a higher level. There is no inheritance from higher levels; that is, Deploy does not combine settings from various directories. If there are no permissions set on a directory, the permission settings from the parent are taken recursively. This means that, if you have a deep hierarchy of nested directories and you do not set any permissions on them, Deploy will take the permissions set on the root node.

All directories higher up in a hierarchy must provide read permission for the roles defined in the lowest directory. Otherwise, the permissions themselves cannot be read. This scheme is analogous to file permissions on Unix directories.

For example, if you have read permission on the Environments root node, you will have read permissions on the directories and environments contained within that node. If the Environments/production directory has its own permissions set, then your access to the Environments/production/PROD-1 environment depends on the permissions set on the Environments/production directory CI itself.

In cases where there is a local version and a global version of a permission, the global permission takes precedence over the local permission at all levels of the hierarchy.