Security

Overview of permissions and security types

A good starting point for learning about the team-based security system is to understand permissions. Build uses the term permission in a way that is familiar to most readers: each permission controls access to a product area or product function. Most permissions refer to typical activities such as creating, reading, updating, and deleting. Permissions define what can be done, not who can do it

A product area that can have defined permissions is referred to as a security type or security resource. Each security type has a set of permissions that affects how users interact with it. The project security type, as the name implies, has a set of permissions that affects a user's ability to interact with projects; the permissions that are available for the agent pool security type affect agent pools, and so forth.

Most security types can have additional types defined for them. Each eligible security type comes with a "standard" type that is defined for it, such as "Standard Process". Each additional type within an area shares the same set of permissions. For example, each agent pool type has the same set of permissions: edit and view. See Security types.

Roles

A role is a set of granted permissions. Defining a role consists of granting permissions for all security types that the role affects. The number of roles and their functions are completely up to you. As delivered, Build provides one role, the administrator role, which has all permissions granted for all security types.

Importantly, a role by itself does not impart its granted permissions to any actual user. Like permissions, roles define what can be done, not who can do them. Roles and their associated permissions are applied to users by teams.

Teams

A team is a construct that associates users or groups with roles. When a user is added to a team, that person is assigned to a role; users cannot be added to a team without a role assignment. Role members are automatically granted all permissions that are defined for the role. Groups can also be added to roles, in which case all group members are automatically granted the permissions that are defined for the role.

When a team is created, all users and groups are available for assignment, and all roles are available for use. Users can be assigned to more than one role. If a user is assigned to one role that grants a particular permission and another role that does not grant that permission, the user is considered to have the permission.

Teams secure resources. To secure a workflow, for example, a team is associated with it. After being secured, only team members who are assigned a role with an appropriate permission can affect the workflow.

Securing resources

The Build security system enables fine-grained customizations. The way all elements come together might not be clear. A further discussion about permissions might provide more clarity.

Two types of permissions are available: types with specific scope; and types with a more general scope. The Job security type has three permissions: create, edit, and view. Except for create, these permissions affect only a specific resource; they are scoped to a specific job. If a team with the edit permission is attached to Job A, for example, then only team members with that permission can edit Job A. Team members with other roles that do not grant the edit permission cannot edit the job. Members of teams that are not attached to Job A cannot edit it regardless of whether they have the edit permission for other jobs.

The create permission is different from other permission types. The create type is not scoped to a specific resource but is more broadly scoped. Team members with a create-type permission can create resources of the related type without first being attached to a specific resource. To continue the job example, users with the create job permission can create jobs even if their team is not attached to a specific job.