Team Foundation Server - 应用程序层到数据层：身份验证，模拟和授权

Question

根据Team Foundation Server Architecture文档 ，在“ 组和权限”部分中：

Team Foundation Server具有自己的一组默认组和权限，您可以在项目，集合或服务器级别设置这些组和权限。 您可以在组和各个级别创建自定义组和自定义权限。 但是，添加到Team Foundation Server的用户或组不会自动添加到Team Foundation Server可依赖的两个组件：SharePoint产品和Reporting Services 。 如果部署使用这些程序，则必须向其添加用户和组，并在这些用户或组在Team Foundation Server中的所有操作中正常运行之前授予相应的权限。

身份验证和假冒：

请通过分析器跟踪，配置片段或Microsoft文章的授权说明（个人，我找不到任何内容）来证明您的答案。

1. 是否从应用程序层到底层Sql Server启用了集成安全性？
2. 如果启用了集成安全性，是否启用模拟（假设标准配置）来模拟应用程序层中用户的身份？
3. 如果启用了模拟，应用程序层是否负责管理基础数据库的安全性？
4. 如果在应用程序层中未启用模拟，那么是否所有与数据层的交互都由TFSService标识完成？

授权：

1. 根据可用知识，是在数据层或应用程序层中评估的授权（即Project.HasWorkItemReadRightsRecursive的值）？

为什么：

我已经编写了一个解决方案，我将客户端进程中的集成安全性通过WCF Web服务传递到使用模拟的Sql Server，从中我可以使用Transact-Sql评估对象授权和角色成员资格。 我们正在讨论这种优缺点作为一种适当的模式，并决定研究TFS如何处理这种情况。

如果您对数据库驱动的应用程序中的对象级别授权有任何更广泛的意见，请随时分享它们。

Answer 1

狂犬病

您正在寻找的大部分内容可以在TFS Web服务的web.config中找到，也可以查看TFS数据库的安全性。

1.从应用程序层到底层Sql Server是否启用了集成安全性？

是。 web.config位于应用程序层服务器上：C：\\ Program Files \\ Microsoft Team Foundation Server 2010 \\ Application Tier \\ Web Services

在那里，您可以找到Tfs_Configuration数据库的连接字符串。 这非常明确地表明它使用集成安全性。

<add key="applicationDatabase" value="Data Source=YOURSQLSERVER\YOURSQLINSTANCE;Initial Catalog=Tfs_Configuration;Integrated Security=True;" />

2.如果启用了集成安全性，是否启用模拟（假设使用标准配置）来模拟应用程序层中用户的身份？

当TFS连接到数据库时，它使用Microsoft Team Foundation Server应用程序池中的凭据，而不是调用最终用户的凭据。 再次从TFS服务web.config ...

    <!-- Disable Identity Impersonation -->
    <identity impersonate="false"/>

事实上，TFS的最终用户对底层Tfs_Configuration数据库没有任何访问级别，这进一步证明了这一点。 （或项目集合数据库，就此而言）

如果在SQL Management Studio中打开Tfs_Configuration数据库并查看Security文件夹，则只会在TFS管理控制台中看到列出的已添加为“管理控制台用户”的用户。

3.如果启用了模拟，应用程序层是否负责管理基础数据库的安全性？

由于对问题＃2的回答，不适用。 但是，答案是肯定的。 当您最初配置TFS时（假设您使用的是Microsoft安装指南，您应该使用它： http ： //www.microsoft.com/download/en/details.aspx ？displaylang = en＆id = 24337），您将设置“TFSSERVICE” “在SQL Server上使用sysadmin或* db_creator *安全角色的帐户。 这允许TFS应用程序层管理其自己的数据库的安全性。 添加新的“管理控制台用户”时，它将授予该用户对TFS数据库的权限。 在将用户添加到管理控制台之前和之后，您可以通过查看Tfs_Configuration数据库的Security文件夹来自行查看。

此外，如果您以无权访问底层数据库的用户身份打开TFS管理控制台，则控制台将加载一堆友好的“用户无权访问数据库”错误消息，而不是填充您希望看到的数据在管理控制台中。

4.如果应用程序层中未启用模拟，那么TFSService标识是否完成了与数据层的所有交互？

是。 我认为上面所说的一切都清楚地证明了这一点 甚至TFS Web Access的应用程序池也在TFSSERVICE标识下运行。 （这是开箱即用的，当然......你总是可以明确地授予对TFS数据库的访问权限，并开始用它来自行解决...你这样做会使你的MS支持合同无效：d）

授权问题：根据可用知识，在数据层或应用程序层中评估授权（即Project.HasWorkItemReadRightsRecursive的值）

此授权（Project.HasWorkItemReadRightsRecursive）在Application Tier中进行评估。 所有工作项和版本控制项都是如此。 为什么？ 因为这是TFS内部安全模型的一部分。 TFS为其版本控制和工作项对象维护了一组广泛的权限，这些权限与底层数据层完全分离。 在版本控制下访问对特定工作项或文件的读/写并不意味着您可以访问包含这些版本控制或工作项对象的数据的SQL表。

这或多或少都在这里拼写出来。 http://msdn.microsoft.com/en-us/library/ms252587(v=vs.100).aspx有服务器级权限，集合级权限，团队项目级权限，构建级权限，工作项权限和版本控制权限。 整个权限系统在TFS应用程序层中编排，而不了解底层数据库架构或数据库安全性。

回应你打开问题的观点

但是，添加到Team Foundation Server的用户或组不会自动添加到Team Foundation Server可依赖的两个组件：SharePoint产品和Reporting Services。

为什么是这样？ 由于SharePoint和Reporting Services都使用类似的模式，其中存在广泛的安全系统，该系统在应用程序层进行管理，但只有一个（或几个）帐户可以实际访问SQL数据库。 即您可以在SSRS中设置Content Viewer，Content Manager等权限，并且可以在SharePoint中设置Contributor，Site Collection Admin，Farm Admin等权限。 您的SSRS服务帐户或SharePoint场管理员帐户将是唯一具有SQL数据库访问权限的帐户。

综上所述

如果您正在开发的应用程序正在获取实际客户端用户的凭据并将它们一直传递到数据库，那么您可能会遇到严重的安全问题。 由于这些用户的帐户将具有直接的SQL访问权限，因此无法阻止他们打开SQL Management Studio，连接到数据库以及执行他们有权访问的任何内容。 也许你的用户不够精明，但为什么要冒这个机会？