Team Foundation Server Security Model Overview


Team Foundation Server uses the concept of permissions to allow certain people to do certain things, while restricting others from doing the same thing. For example, to create a new workspace, your user account, or a group that contains your user account, must have the Create a workspace permission. Team Foundation Server has permissions for most things, from being able to access a project, to being able to start a build. This enables you to fine-tune user's access to team projects and to Team Foundation Server. There are two explicit settings for each permission in Team Foundation Server: Allow and Deny. The Allow setting enables a particular permission. Unless permission is set to Allow, the user or group cannot use that particular permission.

The Deny setting disables a particular permission. The Deny setting always overrides the Allow setting. For example, if you are a member of two different groups, and one group has Allow set for a particular permission, and the other group has Deny set for the same permission, you will not be able to use that permission. Even though one of the groups you are a member of has that permission allowed, because of your membership in the other group, you are blocked.

By default, most permissions are set to neither Allow or Deny. Basically, they are left unset, which is technically a setting of its own. If permission is not explicitly set to Allow or Deny, then by default, the user is denied access to that permission. Team Foundation Server would rather be too stingy with its permissions than too generous.

The Team Foundation Server Security Model also allows for inheritance of security permissions. This ties back into the ability to unset a permission. If you are a member of two different groups, and one group has a permission set explicitly, and it is not set at all in the other group, then inheritance allows you to use the permission as it is set in the first group.

Finally, you can also set security permissions in other parts of Team Foundation Server, specifically in Version Control and in the Work Item Tracking Areas section. The Version Control permissions can be set at the server level all the way down to the individual file level, while the Work Item Tracking Areas section is set at the project level only.

How Team Foundation Server Manages Groups

Team Foundation Server was designed to be easy to administrate. As such, it has its own built-in security model. This permits the Team Foundation Server administrator to deal with security issues, such as creating new groups, adding users to groups, and assigning group permissions, without having to have full access to the Active Directory or other network resources. By providing both UI and command-line tools, the Team Foundation Server administrator can use the tools he feels comfortable with to modify any security permissions.

Team Foundation Server has two levels of groups. Global groups are groups that exist at the server level. These groups provide access to the different server-level permissions. Project groups are groups that exist on the individual project level. These groups provide access to the different project-level permissions.

In addition to these two group levels, which are built into Team Foundation Server, you must also administer groups within Windows SharePoint Services and SQL Server Reporting Services to grant users the ability to create new team projects. Team Foundation Server's security groups are specific just to Team Foundation Server. But the project creation process also requires the ability to set up a Windows SharePoint Services Web site, and the ability to create reports in SQL Server Reporting Services. Therefore, the user needs administrative rights to these other groups. Currently there is no way to give these rights through Team Explorer.

There is, however, an unsupported downloadable tool that provides one common interface to administer users on all three platforms. It's called the Team Foundation Server Administration Tool, and can be found at codeplex.com/Wiki/View.aspx?ProjectName=TFSAdmin. It is worth looking into, as it should save you some time doing administrative work.

Now that we have briefly touched on the different groups, let's dive into each one in more detail.

Built-In Global Groups

Team Foundation Server comes installed with three global groups:

  • Team Foundation Administrators - This group can perform any operation on Team Foundation Server and have total administrative control. It should be restricted to a small number of users.

  • Team Foundation Valid Users - This group allows users access to the Team Foundation Server. It automatically contains any users or groups added to Team Foundation Server

  • Service Accounts - This groups contains the service accounts used by Team Foundation Server.

If you are running Team Foundation Server Workgroup edition, there is a fourth group, called Team Foundation Licensed Users. This group explicitly lists the users who have access to the Team Foundation Server. It can contain a maximum of five users, as the Workgroup Edition is restricted to a five-user maximum.

You can also create new global groups and assign them global-level permissions, as needed. All groups are added to the Team Foundation Valid Users group automatically when created.

Just as there are global groups, there are global permissions related to those groups. The following table shows the different global-level permissions in Team Foundation Server. The Permission column is the name of the permission. The Action ID column specifies the parameter to use when setting this permission via the command-line tools. Notice that some of the rows do not have an Action ID. That is because you will use a different command-line tool, which does not require an Action ID, for setting those permissions. You learn more about that later in this chapter.

The following table shows global level permissions:

Open table as spreadsheet

Permission

Which Means

Action ID

Administer shelved changes

You can delete someone else's shelved changes.

No Action ID for this

Administer warehouse

You can change warehouse settings.

ADMINISTER_WAREHOUSE

Administer workspaces

You can create and delete workspaces for other users.

No Action ID for this

Alter trace settings

You can change trace settings on the Team Foundation Server.

DIAGNOSTIC_TRACE

Create a workspace

You can create a workspace.

No Action ID for this

Create new projects

You can create new team projects.

CREATE_PROJECTS

Edit server-level information

You can edit global groups and their permissions. You can also edit project groups and their associated permissions.

GENERIC_WRITE

Manage process template

You can export, create, edit, and import process templates into Team Foundation Server.

MANAGE_TEMPLATE

Trigger events

You can fire a project alert event in Team Foundation Server. This permission is usually restricted to the service accounts.

FIRE_EVENT

View server-level information

You can view global group membership and permissions but cannot make any changes.

GENERIC_READ

View system synchronization information

You can monitor synchronization of event changes, such as access control list (ACL) changes.

SYNCHRONIZE_READ

This table shows the default Allow permissions assigned to each global group:

Open table as spreadsheet

Group

Default Allow Permissions

Team Foundation Administrators

Team Foundation Administrators have Allow access on all

permissions. This cannot be changed.

Team Foundation Valid Users

Create a workspace

View server-level information

Service Accounts

Administer shelved changes

Administer warehouse

Administer workspaces

Create a workspace

Trigger events

View system synchronization information

Built-In Project Groups

When you create a new team project, project level groups are created for you automatically. What groups are created and what project level permissions those groups have depend on the process model you selected when you created the team project. If you use the MSF for Agile Software Development process, you get the following groups:

  • Build Services

  • Contributors

  • Project Administrators

  • Readers

In addition, the three default global groups, mentioned previously, are also added to the project. You can also create new project-level groups, and give them the appropriate permissions. As with global permissions, there are also project-level permissions. These are permissions that are applied to a specific Team Project. The following table shows the project level permissions for Team Foundation Server:

Open table as spreadsheet

Permission

Which Means

Action ID

Administer a build

You can create, edit, and delete build types, as well as stop builds that are in progress.

ADMINISTER_BUILD

Delete this project

You can delete projects from Team Foundation Server.

DELETE

Edit build quality

You can edit build quality of a build.

EDIT_BUILD_STATUS

Edit project-level information

You can edit the project-level information of a team project.

GENERIC_WRITE

Publish test results

You can add and remove test results from team project portal.

PUBLISH_TEST_RESULTS

Start a build

You can start a build using a build type.

START_BUILD

View project-level information

You can view all build information for builds within a team project.

GENERIC_READ

Write to build operational store

You can update the build database store.

UPDATE_BUILD

This table shows the default Allow permissions assigned to each project group and global group for the MSF for Agile Software Development process model:

Open table as spreadsheet

Group

Default Allow Permissions

Build Services

Edit build quality

Publish test results

Start a build

View project-level information

Write to build operational store

Contributors

Publish test results

Start a build

View project-level information

Project Administrators

Project administrators have Allow access on all permissions. This cannot be changed.

Readers

View project-level information

Team Foundation Valid Users

View project-level information

Team Foundation Administrators

Team Foundation Administrators have Allow access on all permissions. This cannot be changed.

Managing Security in Other Groups

While most of the security settings are handled by Team Foundation Server, you may still need to manage security settings in a couple of other areas. These are in Windows SharePoint Services and SQL Server Reporting Services. To be able to create new Team Projects, you must have the appropriate security settings in WSS and SQL Server Reporting Services. Besides having the TFS Create New Projects permission, a user must have administrative privileges on both WSS and Reporting Services. These privileges are required only if you are wanting to give a user or group the ability to create new team projects. "Giving Users Team Project Create Ability" in Chapter 2 describes in detail how to configure these privileges.

Security in Other Parts of Team Foundation Server

You can set security permissions in two other sections: Version Control and Work Item Tracking Areas and Iterations.

The following table shows the Version Control Permissions:

Open table as spreadsheet

Permission

Which Means

Read

You can read the contents of a folder or file.

Check out

You can check files out of the repository.

Check in

You can check files into the repository.

Label

You can apply a label to items in the repository.

Lock

You can lock an item so no one else can update it.

Revise other users' changes

You can change another user's check-in notes or changeset comments.

Unlock other users' changes

You can remove a lock someone else has on a file.

Undo other users' changes

You can undo a pending change from someone else.

Administer labels

You can make changes to the labels of another user.

Manipulate security settings

You can set the security permissions on folders and files.

Check in other users' changes

You can check in changes made by another user.

This table shows the default Allow permissions assigned to each project group and global group in Version Control for the MSF for Agile Software Development process model. Again, these default permissions are dependent on the process model chosen when the Team Project is created:

Open table as spreadsheet

Group

Default Allow Permissions

Build Services

Read

Check out

Check in

Label

Lock

Contributors

Read

Check out

Check in

Label

Lock

Project administrators

Project administrators have Allow access on all permissions.

Readers

Read

Service accounts

Service accounts have Allow access on all permissions. This cannot be changed.

Team Foundation administrators

Team Foundation administrators have Allow access on all permissions. This cannot be changed.

Using Version Control Explorer, you can get very granular with your security permissions, applying them at the server level, folder level, or even to individual files.

The other section is the Work Item Tracking Areas and Iterations. The following table shows lists the permissions for this section:

Open table as spreadsheet

Permission

Which Means

Action ID

Create and order child nodes

You can create new child nodes and reorder existing child nodes.

CREATE_CHILDREN

Delete this node

You can delete area nodes.

DELETE

Edit this node

You can rename area nodes.

GENERIC_WRITE

Edit work items in this node

You can edit work items in an area node.

WORK_ITEM_WRITE

View this node

You can view security settings for an area node.

GENERIC_READ

View work items in this node

You can view work items in an area node.

WORK_ITEM_READ

This table shows the default Allow permissions assigned to each project group and global group for the MSF for Agile Software Development process model:

Open table as spreadsheet

Group

Default Allow Permissions

Build services

Edit work items in this node

View this node

View work items in this node

Contributors

Edit work items in this node

View this node

View work items in this node

Project administrators

Project administrators have Allow access on all permissions. This cannot be changed.

Readers

View this node

View work items in this node

Team Foundation valid users

View this node

Team Foundation administrators

Team Foundation administrators have Allow access on all permissions. This cannot be changed.

The user who created the project

Edit this node



Professional Team Foundation Server
Professional Team Foundation Server
ISBN: 0471919306
EAN: 2147483647
Year: 2004
Pages: 168

Similar book on Amazon
Professional Team Foundation Server 2010 (Wrox Programmer to Programmer)
Professional Team Foundation Server 2010 (Wrox Programmer to Programmer)
Professional Application Lifecycle Management with Visual Studio 2010 (Wrox Programmer to Programmer)
Professional Application Lifecycle Management with Visual Studio 2010 (Wrox Programmer to Programmer)
Professional Scrum with Team Foundation Server 2010 (Wrox Programmer to Programmer)
Professional Scrum with Team Foundation Server 2010 (Wrox Programmer to Programmer)
Team Foundation Server 2008 in Action
Team Foundation Server 2008 in Action

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net