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 数据库并查看安全文件夹，您将只能看到已在 TFS 管理控制台中添加为“管理控制台用户”的用户列出。

3. 如果启用模拟，应用层是否负责管理底层数据库的安全？

由于问题#2 的答案，不适用。然而，答案是“是”。当您最初配置 TFS 时（假设您使用 Microsoft 安装指南，您应该使用该指南： http: //www.microsoft.com/download/en/details.aspx ?displaylang=en&id=24337 ），您将设置“TFSSERVICE” " SQL 服务器上具有sysadmin或 *db_creator* 安全角色的帐户。这允许 TFS 应用程序层管理其自身数据库的安全性。当您添加新的“管理控制台用户”时，它将授予该用户对 TFS 数据库的权限。您可以通过在将用户添加到管理控制台之前和之后查看 Tfs_Configuration 数据库的安全文件夹来亲自查看这一点。

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

4. 如果在应用程序层中未启用模拟，则与数据层的所有交互是否都由 TFSService 身份完成？

是的。我认为上面所说的一切都清楚地证明了这一点。甚至 TFS Web Access 的应用程序池也在 TFSSERVICE 标识下运行。（当然，这都是开箱即用的...您始终可以显式授予对 TFS 数据库的访问权限并开始自己进行操作...这样做会使您与 MS 的支持合同无效:D)

授权问题：据现有知识，授权是在数据层还是应用程序层中评估的（即 Project.HasWorkItemReadRightsRecursive 的值）

此授权 (Project.HasWorkItemReadRightsRecursive) 在应用程序层内评估。所有工作项和版本控制项都是如此。为什么？因为这是 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 中设置内容查看者、内容管理器等权限，并且可以在 SharePoint 中设置贡献者、网站集管理员、场管理员等权限。您的 SSRS 服务帐户或 SharePoint 场管理员帐户将是唯一具有 SQL 数据库访问权限的帐户。

总之

如果您正在开发的应用程序获取实际客户端用户的凭据并将其一路传递到数据库，您可能会面临重大安全问题。由于这些用户的帐户将具有直接 SQL 访问权限，因此没有什么可以阻止他们打开 SQL Management Studio、连接到数据库以及执行他们有权访问的任何操作。也许您的用户不够精明，但为什么要冒险呢？