Within Azure DevOps, authorizations can be assigned to individual users or to security groups. The security group is either a logical wrapper around an existing AAD group or can be defined within Azure DevOps itself. In general, it is recommended to assign authorizations as much as possible to groups and limit individual user assignments.

To configure the authorizations for a user or security group, two complementary approaches are available:

• Organization- and project-level authorizations
• Object-level authorizations

When working with the on-premises product, Azure DevOps Server, there are also server-level security groups and settings available.

Organization-and project-level authorizations: To allow a user to perform a specific action on every object of a certain type, an organization- or project-level authorization can be set. As an example, look at the built-in groups, Project Collection Build Administrators, respectively, [ProjectName]Build Administrators, which, by default, have permission to view, manage, and edit build definitions and build resources. The permissions that can be set on the organization and project level are automatically applied to all individual resources in the organization or the project.

Object-level authorizations: On most of the objects in Azure DevOps, individual permissions can be assigned to users or groups. These permissions are set using an Access Control List (ACL) on the object itself. The following example shows a classic build definition:

For each group, for each action, it is possible to configure Allow, Deny, Not set, or inherited. When an action is configured with Deny, access is never allowed, not even if a user is part of a group that has the authorization specified as Allow. In other words, when there are two conflicting assignments (Allow and Deny), Deny will take precedence over Allow. Not set is to be interpreted as an implicit deny that does not take precedence. In other words, when there are two conflicting assignments (Not set and Allow), the user will be allowed access.

Some artifacts in Azure DevOps are part of a hierarchy. For example, pipelines can be in a folder. Whenever inheritance is enabled, permissions from higher in the hierarchy will propagate to the artifact. This means that, when a user has access to a pipeline folder, all of their rights will propagate to all underlying folders and pipelines, if and only if, there are no more specific authorizations set.

While the security model determines which authorization a user has, user actions are also limited by their assigned access level, which follows from their license.