Windows Azure 安全最佳实践 - 第 5 部分：基于Claim 的标识，单点登录
基于Claim的身份标识是处理网站与 Web 服务的身份认证和访问一种简单而强大的方式，无论您是在本地工作还是面向云工作。您可以通过减少自定义实施和使用基于Claim的单一简化标识模型，创建更安全的应用程序。
Windows Identity Foundation (WIF)是一组 .NET Framework 类。它是用于在您的应用程序中实施基于Claim的标识的框架。
从架构上说，使用基于Claim的标识可以将应用程序从身份验证业务中脱离出来。单点登录变得更容易实现，您的应用程序不再负责以下操作：
· 对用户进行身份验证。
· 存储用户帐户和密码。
· 调用企业目录以查找用户标识详细信息。
· 与其他平台或公司的身份标识系统集成。
相反，您的应用程序使用颁发机构发到您的应用程序的包含Claim的安全Token。SecurityToken Service(STS)是根据可互操作协议构建、签署和颁发安全token的服务。您的应用程序是relyingparty。
Claim。Claim是您的应用程序需要了解的用户信息。例如，用户的姓名或电子邮件地址，或者是否在销售组织中。您的应用程序将接受以下来源的Claim：
安全token。在 Web 服务中，这些Claim包含在 SOAP envelop的安全头中。在基于浏览器的 Web 应用程序中，Claim从用户的浏览器通过 HTTP POST 到达，而且可能稍后会缓存在 cookie 中（如果需要会话）。
颁发机构。颁发机构是知道如何颁发安全token的 Web 应用程序或 Web 服务。在基于Claim的身份标识的方案中，颁发机构负责发布相应的Claim（如姓名和电子邮件或此人是否在销售组织中）。
Security Token Service(STS)。 STS 同时受客户端和 Web 服务信赖，可提供可互操作的安全token。
Relying Party。即您的应用程序或 Web 服务。它通常被描述为Claimaware应用程序或基于Claim的应用程序。
SAML Token。大多数现有的 STS 都会颁发 SAML（SecurityAssertion Markup Language）token。SAML 是业界认可的基于 XML的语言，可用于以可互操作方式呈现Claim。
场景
有很多种场景。在我选的场景中，用户将其浏览器指向Claim awareWeb 应用程序（relyingparty）。Web 应用程序将浏览器重定向到 STS 以便对用户进行身份验证。
该STS 是一个可读取传入请求的简单 Web 应用, 它通过标准的 HTTP 机制对用户进行身份验证，然后创建 SAML token并生成出一段JavaScript,导致浏览器发送一个HTTP POST将 SAML token发回relyingparty。
POST正文中的 SAML token包含relyingparty所请求的Claim。
您的应用程序接受 SAML token，并通过 Windows Identity Foundation使用几行代码解析token并提取claim。现在您可以访问所请求的数据，如姓名、电子邮件以及此人是否在销售组织中。
我们提供很多其他方案。这个特定的方案使用WS-Trust。
您不必担心您的用户恰好是什么域或安全域的一部分。事实上，您可以支持 Facebook 标识、Windows Live、Google ID 或基于活动目录的用户claim。使用基于claim的身份标识更容易使标识与其他平台或组织进行联合。
WindowsIdentity Foundation 的claim对象模型
您使用 WIF 构建relyingparty时，WIF将屏蔽所有加密相关的繁重任务，WIF（及其基础 WCF ）将为您执行这些任务。它对从客户端传递的安全token进行解密、验证其签名、验证任何证明密钥、将token分成一组Claim并将其通过易于使用的对象模型呈现给您。
在您的代码中，您可以询问token以获取所需的每个Claim。
下面是一个返回电子邮件地址的示例。
protectedstring GetUserEmail(object sender, EventArgs e)
{
IClaimsIdentity id =
((IClaimsPrincipal)Thread.CurrentPrincipal).Identities[0];
// you can use a simple foreach loop tofind a claim...
string usersEmail = null;
foreach (Claim c in id.Claims) {
if (c.ClaimType== ClaimTypes.Email) {
usersEmail = c.Value;
break;
}
return usersEmail;
}
该代码假设已对调用者进行身份验证并已将她和电子邮件地址作为Claim发送。此程序可以作出此假设的原因是因为它具有web.config文件，该文件使用 WIF 中的 WS-Federation AuthenticationModule (FAM) 并为其配置了可以对用户进行身份验证和提供这些类型的Claim的 STS 地址。
FAM 是一个 HttpModule，专门设计为用于简化使用 ASP.NET2.0 构建Claimaware的联合 Web 应用程序的过程。
因此，web.config中需要一些信息，如Microsoft Windows Identity Foundation (WIF) 开发人员白皮书中所述。
WIF提供内置的 Visual Studio 项目模板，用于创建Claim awareASP.NET 应用程序或Claim awareWCF 服务。因此，您可以有一个好的开始。
编写您自己的 STS
您可能已在维护用户名、姓名和密码的成员列表。您可以创建自己的 STS 以提供标识。
STS 可接受传入请求、对其进行验证和解密、将其分成Claim，并为传出安全token以执行相反的操作。WIF 负责处理所有这些繁重的任务。
注意：WIF 不提供用于管理策略的框架，您可以将其视为 STS 后台的逻辑或规则。
将 ASP.NET 成员资格提供程序改造为 STS
如果您正在使用 ASP.NET 成员资格提供程序，可以将其转变为 STS，使其成为您的用户可以用来访问您的应用程序的提供程序之一。您可以通过将简单 STS 添加到 ASP.NET 基于成员资格提供程序的网站，来执行此操作。通过添加包含 WIF 代码的简单页面，可让您的合作伙伴接受您的用户使用他们的网站，甚至为已登录到您的网站的用户启用单点登录。请参阅使用身份提供程序功能改进 ASP.NET 成员资格提供程序网站。
提供单点登录
只要您的应用程序使用Claim，就可以更方便地添加其他登陆。该应用程序仅关注token是否由受信赖提供程序提供。STS 提供应用程序所需的信息，如姓名、电子邮件或此人是否为销售角色。
单点登录 (SSO) 是指用户的token在多个 IT 系统甚至多个组织中受信任。您的应用程序可以使用联合身份作为链接用户的电子标识和属性（存储在多个不同的标识管理系统中）的手段。
在很多方案中，提供用户声明的 STS 作为您的应用程序在同一个组织内部运行。但是现在您的应用程序可以利用组织外部的 STS。
只要应用程序信赖联合提供程序 STS，STS 就可以在任何地方运行—甚至在云中。
WindowsAzure 访问控制是在云中运行的联合提供程序 STS。当您连接到其他组织时，可提供token的 Active Directory 可能无法使用与该组织相同的方式表现角色。访问控制可以直接将各种提供程序的角色映射到您的应用程序使用的名称。
您甚至可以允许从 Facebook、Google、Windows Live 或 Yahoo 等其他提供程序登录。
我将在此系列的下一部分中介绍访问控制。
Windows Identity Foundation 背景介绍
WindowsIdentity Foundation是在 Active Directory 基础上构建的 Microsoft 身份认证和访问管理解决方案的一部分。Active Directory 中还包括以下内容：
. Active Directory Federation Services 2.0：一项 IT 安全token服务，可颁发和转换Claim及其他token、管理用户访问，并实现联合和访问管理以简化单点登录。
· Windows Azure 访问控制服务：提供了一种为 Web 应用程序和服务提供身份认证和访问控制的简单方法，同时与基于标准的身份提供程序集成，包括企业的活动目录（如 Active Directory）和 Web 标识（如 Windows Live ID、Google、Yahoo! 和 Facebook）。
Windows Identity Foundation 入门
. 请参阅 David Chappell 撰写的基于声明的体系结构白皮书。
- 您可以先学习身份标识培训课程。《标识开发人员培训课程》中的视频和动手实验将向您展示如何利用 Windows Identity Foundation 和 Windows Azure AppFabricAccess Control Service等技术，来轻松解决身份验证、授权和身份驱动个性化挑战。完成该课程后，您很快会发现，基于Claim的身份标识使您具备了可重复使用的技能，以保护各种应用程序的安全，包括从 ASP.NET 网站到 WCF Web 服务。
- 另请参阅 Microsoft Windows Identity Foundation (WIF) 开发人员白皮书，其中介绍了如何使用 Microsoft Windows Identity Foundation 开始构建Claim aware应用程序。
. 获取Windows Identity Foundation。
. MSDN 上的Windows Identity Foundation参考。
参考
Windows Identity Foundation (WIF)
下一篇文章
Windows Azure 安全最佳实践 - 第 6 部分：Azure 服务如何扩展应用程序安全性。在最后这一部分，我将说明 Windows Azure 中的其他服务如何为内部部署应用程序提供安全标识映射、消息传递和连接。此部分介绍了 Windows Azure Active Directory、Windows Azure Connect 和 Service Bus 对云应用程序、内部部署应用程序和混合应用程序的影响。
以下是本系列中的文章的链接：
· Windows Azure 安全最佳实践 - 第 1 部分：深度解析挑战防御对策 。
· Windows Azure 安全最佳实践 - 第 2 部分：Azure 提供哪些现成可用的安全机制。
· Windows Azure 安全最佳实践 - 第 3 部分：确定安全框架。
· Windows Azure 安全最佳实践 - 第 4 部分：需要采取的其他措施。
· Windows Azure 安全最佳实践 - 第 6 部分：Azure 服务如何扩展应用程序安全性。
· Windows Azure 安全最佳实践 - 第 7 部分：提示、工具和编码最佳实践。
本文翻译自：
