Security
- To manage permissions or groups at the organization or collection level, you need to be a member of the Project Collection Administrators security group
- There are Access Levels, Security Groups and Permissions
Best Practices
- Don’t change the default permissions for the Project Valid Users group
- Don’t add users to multiple security groups that contain different permission levels
- Take advantage of built-in roles and default to Contributor for developers
Permissions
- Users inherit the permissions assigned to their security group
- Permissions get defined at different levels: organization/collection, project, or object
- Some permissions get managed through role-based assignments (for example, team administrator, extension management, or pipeline resource roles)
- A Deny Permission at a higher level will trump an Allow Permission at a lower level (Exception: Project Collection Administrators and Team Foundation Administrators)
Permission Inheritance
- Explicit permissions always take precedence over inherited ones (but a inherited Deny cannot be overridden)
- Permissions set at a higher-level node get inherited by all subnodes unless explicitly overridden.
- If a permission isn’t explicitly allowed or denied for a subnode, it inherits the permission from its parent
- If a permission is explicitly set for a subnode, the parent’s permission isn’t inherited, regardless of whether allowed or denied
Permission Specificity
- In the object hierarchy, specificity trumps inheritance. The most specific permission takes precedence if conflicting permissions exist
Security Groups
Default Groups
When you create a collection, organization or project, a set of default security groups is created
Organization/Collection Default Groups
- Project Collection Administrators
- Project Collection Build Administrators
- Project Collection Build Service Accounts
- Project Collection Proxy Service Accounts
- Project Collection Service Accounts
- Project Collection Test Service Accounts
- Project Collection Valid Users
- Project-scoped Users
- Security Service Group
Project Default Groups
- Build Administrators
- Contributors
- Project Administrators
- Project Valid Users
- Readers
- Release Administrators
- TeamName Team
Appendix
Roles
Certain permissions are granted with these roles:
- Team administrator role: Team administrators are able to manage all team tools.
- Pipeline security roles: Several roles are used to manage library resources, project-level, and collection-level pipeline resources.
- Marketplace extension Manager role: Members of the Manager role can install extensions and respond to requests for extensions to be installed.
- Artifact or package feed security roles: Roles support various permission levels to edit and manage package feeds.
Objects
These objects can have individual Permissions set on them:
- Areas
- Iterations,
- Version Control Folders
- Work Item Query Folders
Access Levels
Stakeholders
- Stakeholders do not interact with code on the project and don’t need a paid license
- You can have as many Stakeholders on your project as you like
Basic Users
- Basic Users contribute code to the project. They either need to be paid for or need to be assigned a Visual Studio Subscription. Your organization can have up to 5 free Basic Users