Source Access by Branch and Role using Team Foundation Server
It’s great to see the latest version of Team Foundation Server branching guide just passed 30,000 downloads. Even if you are using another source control system I think you will find plenty of the information in the guide is version control system agnostic and hopefully useful to you.
We are planning to update the guide to align the with the release Team System 2010. The revised guide will have the same content plus focus on some of the new features around branching and merging.
One area I’ve been wanting to expand on is how to secure the basic, standard and advanced branch plans presented in the guide. I’m not sure if this will make it into the revised doc so I thought I would post it here just in case.
Regardless of which branch pattern you are using from the branching guide you should have some form of dev/main/release. Below some tips you can use to secure these branches that balance security and developer productivity and also cover vendor access scenarios too. Feel free to adjust as needed depending on your needs.
Source Level Access Type by Group
Unless otherwise specified TFS Application groups should have the access type listed below. Note, FOO (how unoriginal of me) represents your TFS project.
TFS Application Group |
Access Type |
[FOO]\Readers [SERVER]\Team Foundation valid users |
Read |
[FOO]\Build Services [FOO]\Contributors [FOO]\Core_Contributors [FOO]\Release_[xxx]_Contributors [FOO]\Vendor_[xxx]_Contributors |
Read, PendChange, Checkin, Label, Lock |
[FOO]\SCM Admin [FOO]\Project Administrators [SERVER]\Service Accounts [SERVER]\Team Foundation Administrators |
Read, PendChange, Checkin, Label, Lock, ReviseOther,UnlockOther, UndoOther, LabelOther, AdminProjectRights,CheckinOther |
Start at the TFS project level
In Source Control Explorer start at the root TFS project level (e.g. $/FOO). Check in policy and check-in notes are stored as version control annotations at the TFS project level (I just found this out too so don’t feel bad). If users are granted access to the sources further down the source tree but not, at least read access, to the project level, then they will get errors when trying to check in. Note, users granted access to check in deeper in the source tree but not the root level, will ultimately be able to check in. However, the experience is bad due to error popup and check in policies will not be evaluated.
TFS Application Group |
Inherit Permissions |
[SERVER]\Team Foundation Valid Users |
No |
Development Branch Container
Apply to $/FOO/Dev . Use the access types for each TFS application group listed in the section above. Since we do not want the [SERVER]\team foundation server valid users group to have access anywhere in the source tree we remove inheritance at this level.
Since “dev” is really a container for child development branches we only grant access at this level to the build in server groups listed below.
TFS Application Group |
Inherit Permissions |
[SERVER]\Service Accounts [SERVER]\Team Foundation Administrators |
No |
Development Branches
Applies to $/FOO/Dev/dev_xx. Permissions are set at the dev_xx level (i.e. development branches and inherits to all levels below.
TFS Application Group |
Inherit Permissions |
[SERVER]\Service Accounts [SERVER]\Team Foundation Administrators [FOO]\Build Services [FOO]\Project Administrators [FOO]\Contributors [FOO]\Readers |
Yes |
Main Branch
Applies to $/FOO/main – access to main is set at this level and is inherited through main. In general, only members of the Project Admin groups will be checking fixes into main.
TFS Application Group |
Inherit Permissions |
[SERVER]\Service Accounts [SERVER]\Team Foundation Administrators [FOO]\Project Administrators |
Yes |
Release Branch Containers
Applies to $/FOO/release and $/FOO/release/[release name] (e.g. product 1.0). Similar to the development branch container we want to make sure the [SERVER]\Team Foundation Valid Users do not get read access at this level or below from the parent so we do not inherit permissions.
TFS Application Group |
Inherit Permissions |
[SERVER]\Service Accounts [SERVER]\Team Foundation Administrators |
No |
Release Branches
Applies to all release branches under $/FOO/Release/[release]/dev_sp, SP0, SP1, etc. Only members of the [FOO]\Release_[xxx]_Contributors should have access to check into the release branches. In practice, membership to Release_[xxx]_Contributors should be controlled via membership in a local group on the TFS AT (i.e. Release_[xxx]_Contributors is a local group on the TFS AT and is the sole member of the [FOO]\Release_[xxx]_Contributors TFS application group. This will assure that this is no downtime waiting for new membership to be applied via active directory.
TFS Application Group |
Inherit Permissions |
[SERVER]\Service Accounts [SERVER]\Team Foundation Administrators [FOO]\Release_[xxx]_Contributors |
Yes |
Targeted Access
Vendor or contract worker
Members of the [FOO]\Vendor_[xxx]_Contributors group (where xxx is a “friendly” name for their project) should have access to only the directories that they need to do their work. This group is added to the specific directories as needed using the same access type as contributors.
The change here is that vendor permissions are not usually set at the development branch level. You have the flexibility to set these permissions in a very targeted, directory by directly way if needed.
Core contributors
You may want to restrict access to higher value intellectual property or core libraries. In this case you can isolate the folders where this content is in your development branch and add [FOO]\Core_Contributors and deny [FOO]\Contributors and deny [FOO]\Project Administrators. If additional security is needed for sources you may want to consider putting the sources in an offline TFS and only check in a library.
Conclusion
The presented security plan strikes a balance between security and developer productivity. It allows for all development branch activity to be controlled and the branch level. You also have the ability to restrict access to vendors or allow access to more secure sources to core contributors.
When locking down for release you control access through release specific local groups reducing any latency caused by going through a separate or waiting for active directory to reflect the security group change.