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

Comments

• Anonymous
  January 01, 2003
  Hey Derek- The primary reason that I've seen this happen is when folks are talking about the actual Reports that shipped in TFS.  As you know, TFS depends on SQL Reporting Services (SRS) for all reports.  Unfortunately, TFS & SRS do not have an integrated security model to date and thus you've got to give permissions to end-users directly in SRS.   The method I did this for our organization is to provide Authenticated Users access to the TFS Reports in SRS (/servername/reports), then select the collection, and then the project and then click Properties.  For security, select to grant Authenticated Users.  This grants wide-open rights to the content... Let me know if this doesn't help.  If I mis-understood your question, please feel free to correct me and I will try and help again :) Thanks, -Chris

• Anonymous
  January 01, 2003
  Hi Ankit- I'm glad to hear that you migration from VSS to TFS 2010 went well and all things are working.  I've not used Visual SourceSafe in years so for me I'm a bit rusty but here goes. The security model for TFS 2010 is built like the following - Collection Permissions     ---- Project Permissions The users should be added to the valid user at the collection level for them to have "minimal" permissions to see the project.  This allows them to see the projects when you grant them the appropriate rights at the project. At the project level, you need to grant them permission such as contribute to allow them to have read/write to the project.  There is also a group named readers if they only need permissions to read. The permissions, on the other hand, for Source Control are managed independently and this is done by opening Source Control, right-clicking on the root of the projects and setting the permissions.  You can also do this at each project level within Source Control. The following MSDN article msdn.microsoft.com/.../ms252587(v=VS.100).aspx covers this somewhat but I hopefully helped clear it up a bit.   If you have any more questions, please feel free to comment and I will see what I can do to help! Thanks, -Chris Thanks, -Chris

• Anonymous
  August 12, 2010
  What would cause all users to prompted to login to view the report data (ex. Burndown chart)? If they cancel the login they see the portal and the work items, etc., but no the report data in the charts at the top?

• Anonymous
  September 15, 2010
  Hello,      I need help, I have migrated from VSS to Visual Studio TFS 2010. THe migration is succesful however full permission is with each user on all the projects. Please let me know how to assign permission to the users?

• Anonymous
  December 12, 2014
  Very Helpful Post. Thanks Chris!