TFS 2010 Dashboard Permissions when running in SharePoint Server 2010 – Layers & Layers of Security

As you may know, my engineering team migrated off of the Windows SharePoint Services (WSS) and over to a full enterprise edition of SharePoint Server 2010 (MOSS) in order to utilize the deep integration between TFS & SharePoint.  This process is one that, as I’ve mentioned in past blog posts, has a lot of moving parts that encompass a lot of security models throughout.  Let’s just look at TFS out-of-box security to start…

1. TFS:  Security model is built-in whose boundaries include Work Items, Source Control, and Project-level access
2. SharePoint:  Security model is based solely on WSS or MOSS whose boundaries include Document Libraries
3. SQL Reporting Services:  Security model is based solely on SRS permissions who boundaries include all TFS reports

To better visualize this, I like to break down the Visual Studio user interface to explain this -

As you can see, the Security model for TFS is vast and wide including other products in the Microsoft stack.  This is the purpose of today’s post is to breakdown the security model for your TFS Dashboards as they apply because getting permissions correct for your end-users can be tricky.

SharePoint Permissions – Landscape of Dashboard

For each end-user (consumer) of your TFS dashboards, you will need to grant at minimum read permissions in SharePoint.  If the end-user doesn’t have the minimum right then they will return a failure to, though, the failure is different based on the portion of the portal they are accessing.

The above depicts the typical MSF Agile dashboard for a TFS project hosted on MOSS though we’ve removed some reports that are not interesting to us at the current moment (early in project).  To break this down a bit, lets talk about each of the “sections” of the dashboard and where the permissions are stored.

SharePoint – Toolbar, Quick Launch Security

The first permission isn’t actually one that is often not forgotten, but could in some cases so I wanted to cover here.  The key thing to note here is the fact that you are dealing completely with SharePoint permissions and not TFS or Excel Web Services (EWS). 

The red area requires that the user have reader permissions to the SharePoint site.  If they don’t, they will receive the typical SharePoint request for permission request form through a redirect.

To grant the appropriate permissions, you should make sure to do the following -

1. Open the Dashboard using an account that has Site Collection administrator permissions
2. Click Site Actions, Site Permissions
3. Click Viewers
4. Add the User, Group that needs permissions

TFS – Web Parts Data Permissions

The actual permissions to “view” the Web Part is covered by the SharePoint viewer membership, though, not the actual data presented in the Web part.  In this case, to see the data within the Web part the end-user will need READ access to the TFS 2010 Site Collection & Project.  The following landscape on the dashboard are examples of TFS-based Web parts that require READ access within the Team project to successfully view the data -

If they don’t, they will see an error similar to the following:

Any of the TFS Web parts would return Error:  Hover for details and this would result in the following -

“Access Denied:  {user} needs the following permission(s) to perform this action:  View instance-level information.”

Huh?  Instance-level information?  This seems complicated.  It actually isn’t.  This means they need the read permission to the project.  To give the appropriate permissions, do the following:

1. Open Visual Studio 2010
2. Right-click on Team Project (for help on adding a project, go here), select Properties
3. Select Team Project Settings
4. Select Group Membership
5. Locate the built-in group [Project Name]\Readers and double click
6. Click radio button for Windows User or Group under Add member, and then click Add…
7. Add the User or Security group who need access

Have the end-user retry, and they should now have the TFS bar & access to any web part data.

Excel Web Services (EWS) Reports Permissions

The last piece of this security "puzzle”are the permissions for EWS reports.  As mentioned in my previous post, users often will get Access Denied when trying to view excel workbooks via SharePoint.  This is caused by the end-user not having their user (or group membership) defined in the Members portion of the SSS identity wizard.  If your end-user receives the following error within the data area for an Excel Web part, then you need to follow instructions on this blog to give them access -

After you’ve added their user/group to the Members, the end-user should now have permissions to access and view data contained in Excel Web reports.

Summary

As you can see, TFS has some key dependencies on other Microsoft technologies that make the Dashboards light up.  For many, the goal is to see the “shining lights in the sky” which is in the form of pictures & graphs.  This often is not the experience for users of TFS because they see “Access Denied” failures.  The typical TFS administrators might not understand where to look to find the solution.  In today’s post, I hopefully clarified failures and how to provide the correct permissions for the users.

Enjoy!

Thanks,

-Chris