SharePoint 2010 中的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时界面提供了下列认证的选项：