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

时间：2012-03-02 14:09:47

标签： sql-server authentication tfs authorization impersonation

根据Team Foundation Server Architecture document，群组和权限部分：

  

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

身份验证和模拟：

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

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

    5. 授权：

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

      2. 为什么：

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

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

1 个答案:

答案 0 :(得分：3)

狂犬病，

您可以在用于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文件夹，则只会看到列出的用户已被添加为＆＃34;管理控制台用户＆＃34;在TFS管理控制台中。

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

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

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

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

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

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

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

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

回应你用

打开问题的观点
  

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

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

总结

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

相关问题
最新问题