Open topic with navigation
ARA Folder Permissions
The security concept of ARA is based on the concept of folder permissions, create type permissions, approvals, and login objects.
The create type permissions controls your permission to create new entities of a certain type, for example, a Production Environment. If you do not have create permissions for a certain type, you may still have the permissions to work with entities of that type, but cannot create new entities.
Create permissions for types are granted and revoked by an administrator on the Permissions page of a user or user group definition. For information, see Assigning Release Automation Permissions. Alternatively create permissions for types can also be granted and revoked via the Admin Command Line Interface.
The folder permissions controls what you are allowed to do with entities in a folder. Whenever you create a new entity, you store it in a folder (e.g. RELEASES). Depending on the permission you have on the folder you can do different things with entities in that folder. There are 5 different permissions which can be set per folder and user/group by an administrator:
- read: You can access the folder and view all entities within it
Note, that you cannot reference entities within this folder from other entities.
Some entities may be visible even if you don't have read permissions on them. In ARA, if a user has read permissions on a top-level entity (e.g. Application) he/she can see its sub-entities as well (but not its properties). E.g.: if you can access an Application, you'll be able to see the Application Packages. When the Package State change is triggered and the Package is stored in another folder where you don't have any permissions, the Package will still be shown in the Application Dashboard and in the Package list. A "permission denied" message suggesting you to contact the owner will be displayed in the right sidebar.
- use: You are allowed to reference entities in this folder from other entities
Example: If you want to assign an environment to a deployment profile, you require use permissions on the folder in which the environment is stored.
- write: You are allowed to change entities in this folder
Example: When you want to assign an environment to a deployment profile, you require write permissions on the folder in which the deployment profile is stored.
-
delete: You are allowed to delete entities in this folder
-
execute: You are allowed to use the entity when executing a workflow
The following entities are stored in dedicated folders:
- Activity, Activity Template, Application, Component, Deployment Profile, Deployment Target, Environment, Environment Reservation, Login, Package, Queue, Release, Workflow (Application and General).
The folder permissions are managed on the Folder Authorizations page of a user or user group definition by an administrator.
Approvals add another security layer to workflow executions and activities. An administrator can configure via approval rules, who needs to approve a workflow execution based on the context of the execution (e.g. to which environment a package gets deployed). Workflows will only start if all approvers give their OK. See Handling Approval Requests Handling Approval Requests (ARA User Guide).
Approval requests are managed on the Approvals page of a user or user group definition by an administrator. For more information see About Release Automation Approval Subscriptions.
Login objects store the credentials of users that are used for the actual execution on a target machine by an agent. See Working with Login Objects for details.
Plan and implement an authorization system, set appropriate rights and privileges across the entire ARA system.
Open topic with navigation
