TFS security can be an interesting beast to work with from an administration point of view.
Not only do you have to manage the permissions assignments in 3 different places (TFS, SharePoint and Reporting Services), but the TFS security model takes on a very layered approach, where different permissions apply on different “levels”.
Most of the groups discussed below are configured and maintained in TFS, so where possible you would probably want to create Active Directory Groups and have these assigned to the correct TFS, SharePoint and Reporting Services groups. This allows you to assign and remove users from a single point (AD) and then this applies across the board.
Additionally TFS rights can be either “Allowed”, “Denied” or “Unset”. Unset means they are neither denied or allowed and means that the inheritance of that right from another group takes precedence. Also note that “Deny” takes precedence in most cases.
If you appear in two groups, one group allowing a feature and in another group that feature is denied, you will have that feature denied. The only exception is if you exist in an administrators group (“Project Administrators”, “Project Collection Administrators” or “Team Foundation Administrator”), the deny is overridden by the rights assignment in the administration group for the associated level.
Administration Console
This level is really assigned to individuals who are responsible for the administration of TFS itself. You cannot assign groups into this role (only users) and assigning this actually modifies rights on the physical aspects such the databases, SharePoint etc.
I would recommend that you limit the amount of users in this group to administrators responsible for TFS maintenance and high level configuration.
Server Level Permissions
Focussed more at operational aspects of TFS on a server level and not specific to a project collections. These groups can only be modified from within the TFS Administration Console.
The default groups created at this level are:
- SharePoint Web Application Services
- Team Foundation Administrators
- Team Foundation Service Accounts
- Team Foundation Valid Users
- Work Item Only View Users
This is where you assign permissions such as being able to create or delete project collections. The “Team Foundation Valid Users” and “Team Foundation Service Accounts” groups cannot be added to directly. The “Valid Users” group is an aggregated list of all the Server Level Permissions as well as the individual Project Collection “Valid Users” groups’ and merely assigns access to the TFS Web portal and viewing instance related information. The “Work Item Only View Users” is a group where you would typically assign project managers or the likes, that is only able to create and manage work items from the web portal, in other words you do not see build information and source code browser etc..
Permissions available on this level include:
- Administer Warehouse
- Create team project collection
- Delete Team project collection
- Edit instance-level information
- Make requests on behalf of others
- Use full Web Access features
- View instance-level information
Collection Level Permissions
These are specific to the project collection. The reason for having this level is to segregate project collections from each other, providing something of a contained “eco-system” for each project collection. These can be modified from the TFS Administration Console as well as directly through Team Explorer.
The default groups created at this level are:
- 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 Collection
As you can probably deduce from the names – these are still very much administration related groups, but as mentioned previously contained to a project collection.
Permissions available on this level include:
- Administer shelved changes
- Administer workspaces
- Alter trace settings
- Create a workspace
- Create new projects
- Delete team project
- Edit collection-level information
- Make requests on behalf of others
- Manage build resources
- Manage process template
- Manage test controllers
- Manage work item link types
- Trigger Events
- Use build resources
- View build resources
- View collection-level information
- View system synchronization information
Project Level Permissions
This level is specific to a project and can only be managed through Team Explorer. This is also where things become interesting… setting permissions on this level, you need to consider the Build, Area’s, Iterations and Version Control, as each exhibits its own set of permissions. So to draw a comprehensive security model on this level you would need to draw together all the required permissions and then allocated the appropriate permissions in each of these functional areas. Once again if you have a large number of teams working on different projects, Active Directory Groups are definitely the way to go.
The number of default groups are small and include merely:
- Builders
- Contributors
- Project Administrators
- Readers
Areas and Iterations:
To my mind these are ways of grouping work. They are very similar in structure with only the permissions between the two differing. I quite like the
description of having Areas denote the “logical, physical, or functional” grouping vs. Iterations that denote the time based grouping.
Right click on the project name in Team Explorer and select “Team Project Settings” then “Areas and Iterations”. This will display the dialog for managing the Areas and Iterations. At the bottom of the dialog next to the “Close” button you will find the “Security” button.
The permissions can be set at each node of the hierarchy and the permissions set at the lower nodes override the inherited permissions.
Permissions include:
Areas:
- Create and order child nodes
- Delete this node
- Edit this node
- Edit work items in this node
- Manage test plans
- View this node
- View work items in this node
Note the work item permissions here. This allows you to “group” work items in the project and only allow certain users to “see” certain work items. This comes in handy when you subscribe to having a single project containing a number or individual projects.
Iterations
- Create and order child nodes
- Delete this node
- Edit this node
- View this node
Build
These permissions are specific to the build infrastructure that TFS provides. In Team Explorer under the appropriate project right click on the “Build” node and select “Security”.
Permissions available here are:
- View builds
- Edit build quality
- Retain indefinitely
- Delete builds
- Manage build qualities
- Destroy builds
- Update build information
- Queue build
- Manage build queue
- Stop builds
- View build definition
- Edit build definition
- Delete build definition
- Override check-in validation by build
Source Control
The version control repository where all files are checked into. Open the source control window by double clicking on “Source Control” node under the appropriate project. You should see the source control layout that looks similar to a folder structure. Right click on any of the “folders” select “Properties”. The dialog that is displayed will have a “Security” tab on. Note that if you have a folder marked as a branch the dialog looks different and the security functionality is under the “Permissions” tab. Similar to the Areas and Iterations the inherited permissions are overwritten.
Permissions available here are:
- Read
- Check out
- Check in
- Label
- Lock
- Revise other user's changes
- Unlock other user's changes
- Undo other user's changes
- Administer labels
- Manage permissions
- Check in other user's changes
- Merge
- Manage branch
The TFS security model does give you a lot of flexibility, but it is not always that easy to navigate and manage. I have come across very few instances where there was a need to create additional groups within TFS, the default groups that are created are adequate for most deployments. If the need does arise to create custom groups, you should be aware of all the various aspects that it may encompass.
