SharePoint 2010 中的BCS身份验证模式
BCS（Business Connectivity Services）是SharePoint 2010中用于替换原先Microsoft Office SharePoint Server 2007企业版的业务数据目录（Business Data Catalog ，简称BDC）的一项新服务。 BCS相比BDC而言有许多改进，包括回写到数据源的功能，通过类似SharePoint Workspace的Office套件提供脱机功能，增强的工具集以及外部列表等等。在这篇文章中我们将探讨BCS认证的相关内容，包括你可能会遇到的一些问题，以及克服或解决其中的一些问题的若干方法...
BCS（Business Connectivity Services）是SharePoint 2010中用于替换原先Microsoft Office SharePoint Server 2007企业版的业务数据目录（Business Data Catalog ，简称BDC）的一项新服务。 BCS相比BDC而言有许多改进，包括回写到数据源的功能，通过类似SharePoint Workspace的Office套件提供脱机功能，增强的工具集以及外部列表等等。
在这篇文章中我们将探讨BCS认证的相关内容，包括你可能会遇到的一些问题，以及克服或解决其中的一些问题的若干方法。
谈到连接后端数据源进行认证，通常不外乎有两种身份验证的类型：用户身份标识和模拟用户权限提升。用户身份标识就是指我们登录网站实所使用的用户标识，直接把它传递给数据源，并返回数据到 SharePoint。用户会根据自身身份标识的不同看到基于该用户身份的内容；模拟用户权限提升时，用户登录时使用他们自己的凭据，但连接数据源时使用另一个用户的凭据，通过模拟其他有权限访问数据源的用户来获取数据。两者各有优缺点。
企业希望将用户的身份传递给数据源，这是一个很普遍的需求。 这种直接传递往往在开发环境中运行良好，可一旦迁移到生产环境就会遭遇失败。究其原因就是众所周知的双跃点问题（Double Hop Issue）。 双跃点问题在BDC时代就已经存在了，BCS中仍然存在该问题。这与其说是一个SharePoint的问题，倒不如说是浏览器/ IIS的问题。当我们通过直通（PassThrough）方式连接到数据源时， Windows身份验证的用户安全令牌只能进行一次跳跃。就是从浏览器到IIS的一跳。在一个开发环境，通常数据库服务器安装在与IIS同一台物理机器上，因此一跳就可以满足要求了。然而，在生产环境中，通常很难碰到只有一台机器的情况，因此凭据传递必须从浏览器到IIS再到SQL。用户因为这两次跳跃从而无法通过验证。
在仍然要保证用户身份的前提下，双跃点问题的一种解决方法是，配置我们的环境使用Kerberos认证。 如果你目前的配置架构中并没有使用Kerberos，想要突然改变一切，让用户都使用Kerberos进行SharePoint身份认证是很困难的，而且也很难得到你的管理员认可。Kerberos身份验证可以通过设置服务器间（比如IIS和SQL）的信任关系来避免双跃点问题。验证合格的凭证，会在IIS服务器上被续签（renew），进而继续用于SQL服务器。
如果传递用户身份对你来说并不重要，那么你可以使用模拟用户的方式进行数据源认证，从而克服双跃点问题。Business Connectivity Services认证中的一个选项是“RevertToSelf”。 当选择RevertToSelf时并不会以用户身份，而是使用了进程帐户（也就是BCS运行时服务所用的帐户)身份进行数据源验证。这也就是意味着，每个SharePoint用户无论其身份如何，都将使用相同的帐户连接到数据源。这听起来像一个安全问题，但实际上这种方式工作的非常好。因为你还可以在SharePoint级别上为每个用户或组指定权限。 比如你可以在SharePoint中指定执行功和写回的权限。这样就可以弥补安全方面的问题。这种方式确实可以称为最佳实践了。因为你可以在SQL里分配每个表，视图，存储过程的权限，然后将定制好的SQL权限直接分配到某个 SharePoint用户帐户。
Business Connectivity Services认证支持的另一种方法是使用安全存储服务（Secure Store Services ，简称SSS）。安全存储服务（SSS）是SharePoint 2007中的单点登录（Single Sign On ，简称SSO）的升级换代。 SSS为我们提供了一个选择，可以将凭据存储在安全存储数据库（驻留于SharePoint服务器）中。然后，凭据以“用户到用户”或“域组到用户”的方式进行映射。这样凭据就可以在SharePoint服务器上进行续签(renew)。 有关SSS 我们会单独在一篇博文中进行讨论。
我们无法做到真正推荐一种BCS认证机制可以用于所有的组织机构或企业公司。因为每个组织都有自己不同的环境配置和管理策略，因此只能提供若干种选择。
在SharePoint Designer 2010里，连接到SQL Server时界面提供了下列认证的选项：
- 使用用户标识进行连接
- 使用模拟Windows标识进行连接
- 使用模拟自定义标识进行连接
以上我们介绍了BCS身份验证的类型。接下来我们将深入到每一种认证类型的细节，看一下具体如何在SharePoint Designer 2010中设置PassThrough 和 RevertToSelf身份验证模式。
首先介绍一下界面上的这些选择项：
用户标识
使用用户标识进行连接，其实就是曾在BDC认证中用过的名为直通(PassThrough)的验证方式。这意味着，Windows身份验证的用户安全令牌将被从浏览器传递给IIS，然后再传递到SQL。这个种方式在开发环境中往往没问题，但是部署到生产环境可能会遇到上面谈到的双跃点问题。
模拟Windows标识
剩下的两个选项都是指向安全存储服务（SSS）。SSS将会在接下来的博文中进行全面解释。 SSS允许我们通过Windows用户，或者某个自定义账户，比如一个联盟的SAML用户帐户进行数据源连接。
RevertToSelf
在上面的对话框中你不会看到“RevertToSelf”的选项。要配置RevertToSelf时，首先要选择 “使用用户标识进行连接”，然后点确定。当连接建立好后，再选择功能区中的“编辑连接属性”，修改身份验证的方式，如下图所示。
这里可以选择是用用户标识（PassThrough）还是BDC标识（RevertToSelf）进行连接。你要确保相应的标识对数据源具有读写权限。如果选择了SSS，你还要进行一些额外的配置步骤。
在接下来的博文中，我们将描述如何在SharePoint 2010中配置安全存储服务（SSS）。
参考资料
