Partager via

To project and serve

  • Article

I'm doing a lot of work around the Group Security Subsystem (or Group Security Service, depending who you ask), also known as "GSS". GSS manages the basic permissions for all of Team Foundation Server. GSS comprises both a permissions model (allow/deny) and a group heirarchy. External users and groups can be added to TFS groups, and TFS groups can be added to one another. Permissions can be either directly assigned to external users and groups or to TFS groups.

TFS groups can be created either on the server level or within a particular team project. There's an interesting distinction between the two. In the Team Foundation world, you can think of the Team Foundation Server  security model like the pattern on a ladybug's back. The red is the server scope, while each individual black dot is a team project. Hence, server level groups can be granted permissions within any project (and can also be made members of project level groups). Project level groups, on the other hand, can't be made members of server level groups - their scope is limited to just their respective projects, at least from the UI. You can use the TfsSecurity.exe command line tool on the AT to add project groups to server groups, or project groups to another project's groups, but most users don't have read access to that tool.

There are also different permissions on the Server and Project level. The server level permissions are:

  • Administer shelved changes
  • Administer warehouse
  • Administer workspaces
  • Alter trace settings
  • Create a workspace
  • Create new projects
  • Edit server-level information
  • Manage process template
  • Trigger events
  • View server-level information
  • View system synchronization information

The Project level permissions are:

  • Administer a build
  • Delete this project
  • Edit build quality
  • Edit project-level information
  • Publish test results
  • Start a build
  • View project-level information
  • Write to build operational store

There are also two other sets of permissions. One is the Work Items "Areas" permissions, which are basically an extension to the project level permissions (they allow more fine-grained control of work items), and the other is the Version Control item permissions which are tied only to specific Version Control item paths independent of team projects. From the Source Control Explorer UI, though, you can't assign permissions to other project's groups, only to the current project's groups, server level groups, and external users and groups.

If you have a user who should have permissions to two Team Projects, but not a third, you can either add that user to two different Project groups, or one Server group that has been added to only groups in both projects. Better yet, create an external group and add all the users in the same situation to that group and then assign TFS permissions to the group (or add it to the necessary TFS groups). If this user only need source control access to a few items or folder trees in each project and should be denied access to everything else, it's best not to add them to one of the builtin groups (i.e. Contributors, Readers) since those are granted Version Control permission to the root folder of each Team Project.

 Anyway, I hope I haven't completely confused you- basically, think lady bug, but will some command line ways of bleeding the dots together.