Ever wondering how TFS Proxy works?  While this MSDN article "Team Foundation Server Proxy and Source Control" ( http://msdn2.microsoft.com/en-us/library/ms252490.aspx ) provides a great overview, this blog post will add an end-to-end story for TFS users who likes to dig into technical details.

Table of Contents:

  • Workflow
  • Highlights
  • In other words

Workflow:

Let's see what happens among a user (CLIENT), TFServer (SERVER) and TFS Proxy (PROXY) when the user is trying to download a file from TFServer version control repository.

  1. CLIENT authenticates with SERVER.
    1. SERVER terminates connection if authentication failed.  End of story.
  2. CLIENT sends a file download request to SERVER.
  3. SERVER checks CLIENT's read permission on the requested file.
    1. SERVER reports "file does not exist" to CLIENT if CLIENT has no read permission.  End of story.
  4. SERVER sends a download ticket for the requested file to CLIENT.
  5. CLIENT sends the download ticket to PROXY and wait for PROXY to return the requested file.
    1. Update: If PROXY does not return the requested file within a certain amount of time for any reason, CLIENT will use the download ticket to download directly from SERVER.  End of story.
  6. PROXY checks whether the requested file is already cached.
    1. PROXY returns the requested file to CLIENT if it is already cached.  End of story.
  7. PROXY service account authenticates with SERVER
    1. SERVER terminates connection if authentication failed.  PROXY reports error to CLIENT.  CLIENT will download directly from SERVER.  End of story.
  8. PROXY asks SERVER for the location of VersionControl services.
  9. SERVER checks whether PROXY service account has read permission on server-level information.
    1. SERVER terminates connection if PROXY service account has no read permission on server information.  PROXY reports error to CLIENT.  CLIENT will download directly from SERVER.  End of story.
  10. SERVER tells PROXY where VersionControl services are.
  11. PROXY uses CLIENT's download ticket to download the requested file from SERVER.
  12. PROXY caches the requested file.
  13. PROXY returns requested file to CLIENT.  End of story.

Highlights:

  1. SERVER always checks repository read permission against CLIENT, not PROXY service account.
  2. SERVER always checks server-level information read permission against PROXY service account; and that is the only permission PROXY service account ever needs.
  3. PROXY can save SERVER resources by serving CLIENT's downloading request when the requested file is already cached.

In other words:

  1. PROXY and SERVER are binded at the server-level, not team project level.
  2. PROXY does not act as a surrogate for SERVER; PROXY only does caching and all permission checking is done by SERVER.
  3. PROXY service account can simply be placed in a server-level group, e.g. "[Server]\Proxy Service Accounts", without any extra security configuration.  This effectively grants PROXY service account read permission on server-level information.
    1. Adding PROXY service account to either TFServer Admin group, TFServer service account group, or any team project group will also grant PROXY service account read permission on server-level infromation; however, this practice is not recommended because it gives PROXY service account more permissions than it needs.