为何使用基于声明的标识
上次修改时间： 2011年2月16日
适用范围： SharePoint Foundation 2010
基于声明的标识是 Microsoft SharePoint Foundation 2010 和 Microsoft SharePoint Server 2010 中的一个标识模型，其中包含跨基于 Windows 的系统的用户和非基于 Windows 的系统的用户的身份验证、多种身份验证类型、更强大的实时身份验证、更广泛的主体类型以及应用程序之间的用户标识委派等功能。
不同的身份验证系统
大多数企业应用程序都需要一些基本的用户安全功能。至少，企业应用程序需要对其用户进行身份验证，而且很多企业应用程序还需要对某些功能的访问进行授权，以便只有那些具有特定权限的用户才可以对其进行访问。有时，这些授权规则需要在现有用户安全令牌中找不到的属性。例如，在 SharePoint Server 2010 中，可以使用 Microsoft Exchange Server 中的通讯组列表作为一个主体，从而保障某些对象的安全。这些安全功能可以内置在 Windows 操作系统中，并且通常情况下很容易集成到应用程序中。通过利用集成的 Windows 身份验证，您无需创建您自己的身份验证协议，也无需管理一个用户数据库。通过使用访问控制列表 (ACL)、模拟以及类似于分组这样的功能，您可以在无需编写很多代码的情况下实现身份验证。
与 Windows 类似，SharePoint Foundation 2010 和 SharePoint Server 2010 提供了一组功能用来帮助完成授权任务。对于某些对象（例如，网站对象）而言，这些功能会在后台自动执行。无论您使用的操作系统或应用程序如何，这一准则均适用。与内置的 SharePoint 安全功能紧密集成差不多总是胜过自己重新创建这些功能。
但是，如果您想要连接到没有 Windows 帐户的用户，将会发生什么情况？而对于根本就未运行 Windows 的用户又会怎样？越来越多的应用程序需要这种类型的访问以连接这些类型的用户，而这看起来违背了传统的安全要求。基于声明的标识是 SharePoint Foundation 2010 和 SharePoint Server 2010 中新的标识模型，旨在帮助您解决这些问题以及其他问题。
在 Windows 中，用户的域帐户是用来访问企业应用程序最常用的凭据类型。使用集成的 Windows 身份验证的应用程序接收一张 Kerberos 票证以代表某个客户端，而使用安全套接字层 (SSL) 的应用程序则可能会接收到客户端的 X.509 证书。Kerberos 票证与 X.509 证书是两个完全不同的项目，操作系统中用来分析、验证并最终呈现内部数据的代码也大不相同。不过，如果您再仔细想想它们所真正代表的含义，您就会发现，这两个凭据还是有许多相同之处。
设想一下下面的这种情况。Alice 是一名想要通过使用其 Windows 域帐户来访问采购服务的用户。首先，她的域控制器会对她进行身份验证，然后创建一张包含一组安全标识符 (SID) 的 Kerberos 票证。这些 SID 代表 Alice 的用户帐户以及她作为成员所在的域组。SID 嵌入在票证中并带有域控制器签名。从标识方面来说，"颁发者"（域控制器）将提供给主体 Alice 一个安全令牌，她可以使用此令牌证明其身份。当 Alice 改为使用证书时，这些想法仍然适用。证书只不过是另一种类型的安全令牌。在这种情况下，颁发者是证书颁发机构 (CA)，而主体是 Alice。实质上，Kerberos 票证和证书都是颁发者关于主体的经签名的声明。这些是受信任的颁发机构可以为其某个主体之一提供担保的两种不同的方式。每个经签名的声明都可以被看作是一个声明集合。换而言之，一旦域控制器对 Alice 的票证中的 SID 列表进行签名，即表示它正在进行有关 Alice 的标识的声明。每个 SID 都将成为一个声明。而证书颁发机构是在它对 Alice 的名称和公钥进行签名时进行有关 Alice 的身份的声明。而名称和公钥是证书中的声明的示例。
这个新的标识模型的目标是通过一种方式来将标识抽象化，以便在不损害应用程序的安全性的情况下，减少对特定类型的凭据的依赖性。通过对 SharePoint Server 2010 中的标识模型进行编码，您可以在无需 Kerberos 票证的情况下，处理委派用户的标识，而且还可以处理安全声明标记语言 (SAML) 令牌。这将为使用某些有用的标识体系结构（包括联合标识）打开方便之门。