本文简介 .NET 新一代的 Windows Identity Foundation (WIF) 框架，及其与 WCF 的协同运用。文后提供两本 WCF 4 书籍、一本 WIF 书籍的下载地址，及许多网络上的学习资源。
本帖并非要详述 WIF 的功能细节，事实上重点在文后的 30 多项学习资源，提供网友将来需要学习时作为参考。不然此等新技术，等到它普及不知要多少年后。一般传统产业、非软件公司的 IT 部门，可能到现在连 WCF、WF 都没听过，小弟我还知道台湾某些金融业的开发部门，还在用 .NET 1.1 / VS 2003 开发，系统只求稳定即可；至于新技术...，浅尝学习一下即可 (除非时间太多)，重点在于怎么搭配产业 know-how 和企业的需求，以作导入与否的评估。
书籍下载地址，请参考文后「学习资源」的 [3], [31]。本帖后续也简单介绍「Programming WCF 4 (Wrox)」这本书第九章里，与 WIF 有关的部分内容。
图 1 书籍封面及目录
若您下载「Programming WCF 4 (Wrox)」书上的代码，发现编译时找不到「Microsoft.IdentityModel 程序集」，那是因为您的 Windows 尚未安装 WIF。只要去微软的网站下载和安装 [7] (安装文件仅约 1.5 MB)，Visual Studio 2008/2010 即可正确编译。以下是 WIF 安装的系统需求
------------------------------------------------------
WIF 安装需要下列操作系统之一：
* Windows 7（32 位或 64 位）
* Windows Server 2008 R2 （64 位）
* Windows Server 2008 + Service Pack 2 （32 位或 64 位）
* Windows Vista + Service Pack 2 （32 位或 64 位）
* Windows Server 2003 + Service Pack 2 （32 位或 64 位）
* Windows Server 2003 R2 （32 位或 64 位）
WIF 需要有下列 .NET 版本或更高之版本：
* .NET 3.5 + Service Pack 1
------------------------------------------------------
至于 Windows Identity Foundation (WIF) 为何物？我曾在今年年初的「dotNET Framework 4 新版 API 和命名空间」一文中 [2] 有稍微提到，当时并提供 .NET 4 的海报 pdf 下载，其类库在 .NET 4 新建的内容如下图 2，除此之外的命名空间应是在 .NET 3.5 时代即已存在 [6]。
图 2 WIF 在 .NET 4 里新加入的命名空间和类
Windows Identity Foundation (WIF, Windows 身份验证基础)，先前代号为 Geneva 框架。若要用最简单的几句话来介绍，其为微软 .NET 平台的一个身份标识新框架，它将 WS-Trust 和 WS-Federation 协议抽象化，帮助开发者从应用程序中排除掉身份验证的处理，只用单一的编程模式和工具，即可构建基于「声明」的身份验证、授权、及其他安全功能，改善开发者生产力 (避免过去应用程序复杂的认证过程)、增强程序安全性、提供协同合作性，以在 Azure 云端，或非云端的 ASP.NET 与 WCF 应用程序，实现「单点登陆 (SSO)」、个性化、联合化、强验证、身份验证委托，以及其他验证功能。 WIF 可便捷地将非云端应用程序迁移至 Windows Azure (从身份验证的角度），反之亦然 [10], [16]。
在WIF中，除了更容易实现单点登录，且应用程序不用再负责以下操作 [4]：
对用户进行身份验证。
存储用户帐户和密码。
调用企业目录以查看用户标识的详细信息。
从其他平台或公司，与既有的标识系统集成。
WIF 可用于任何使用 .NET 3.5 SP1、.NET 4 的 Web 应用程序或 Web 服务。但 WIF 只是微软的「联合身份标识」软件系列的一部分。「联合身份标识」包含三种组件：Active Directory Federation Services (ADFS) V2 (之前称为「Geneva」服务器)、Windows CardSpace、WIF。 这三种组件共同构成了微软基于「声明」的新访问平台其核心。
对于使用 WIF 的 WCF 服务，开发者不再需要用典型 WCF 身份验证和授权行为初始化 ServiceHost 实例。WIF 取代了这些行为，并提供更简洁的方式进行一般的安全配置、身份验证设置 [5], [17]。
ServiceHost 类 (.NET 4、.NET 3.5)
http://msdn.microsoft.com/zh-cn/library/system.servicemodel.servicehost.aspx
http://msdn.microsoft.com/zh-cn/library/system.servicemodel.servicehost%28VS.90%29.aspx
WSTrustServiceHost 类
http://msdn.microsoft.com/zh-cn/library/ee735268.aspx
图 3 WIF 的 WSTrustServiceHost 类，继承自 WCF 的 ServiceHost 类，并添加了「安全令牌服务 Security Token Service (STS)」的功能
WIF 框架提供了用于托管 STS 实例的自定义 ServiceHost 类型 WSTrustServiceHost。下方代码说明了如何在自托管环境中构造 WSTrustServiceHost 类型 [20]：
图 4 书中第九章的示例，用 STS 项目、WSTrustServiceHost 类的实例，做 WCF 的自托管 (Self-hosting)
书上也有对「安全令牌服务 (STS, Security Token Service)」和「安全声明标记语言 (SAML, Security Assertions Markup Language)」的介绍。若搭配 MSDN Magazine 的图片和中文说明，会更容易了解 [19]。
图 5 STS 实现了 WS-Trust 规格，可处理不同类型凭据的身份验证，以颁发出安全令牌，大幅简化 ASP.NET、WCF 等不同应用程序中的验证和授权代码
书上和 MSDN Magazine 也有提到，用 STS 达到跨域做单点登录的议题 [19]。在联合方案中 (Federation Authentication)，STS 可在两个或多个安全域之间建立信任关系，以便用户可以对管理其凭据的域进行身份验证，同时仍可获得另一个域中资源的访问权限，如下图 6。因为 STS 会对其中一个域 B 的用户，在进行身份验证后，颁发携带声明的 SAML 安全令牌，里面包含了被验证用户的身份标识、用户的访问权限，然后此令牌会作为 Cookie 返回到浏览器，如上图 5；之后当用户浏览至域 A 中的 Web 应用程序，会将 SAML 令牌作为 Cookie 进行传递，此时由于两个域中的 STS 存在信任关系，域 A 中的 STS 会信任此令牌的签名。
图 6 使用 STS 达到跨 Domain 做 SSO (Single Sign On)，无需再跨多个应用程序和域维护用户凭据
通过使用诸如 Active Directory Federation Server (ADFS) 和 WIF 的联合安全平台，在域之间添加新的信任关系也变得更加容易。将应用程序扩展到企业实体内的其他域，甚至扩展到外部合作伙伴的域也变得更容易 [17]。
另附带一提，微软云计算 Windows Azure AppFabric 服务，包含 Access Control、AppFabric Service Bus 两大服务功能。前者 (ACS, Access Control Service) 对用户访问的安全权限控制，也与 STS、SAML Token、声明式的授权有关，以避免某些复杂的验证过程。 Azure 应用程序取得 Token 其步骤大致如下：
1.用户将它的 SAML Token (Security Assertions Markup Language) 传送给 Access Control Service。
2.STS (Security Token Service) 依据规则，产生新的 SAML Token。
3.在访问控制内的 STS，将新产生的 Token 传送给客户
4.客户端再将新产生的 Token 传送给应用程序 (如上图 5 的 WCF、ASP.NET、...)
5.应用程序就依据这个 Token，来决定用户的权限为何、能做什么、...等
----------------------------------------------------------------------------------------
附注：名词解释 1
http://msdn.microsoft.com/zh-cn/magazine/cc948343.aspx [18]
http://msdn.microsoft.com/zh-cn/library/ee748490.aspx
安全令牌服务 (STS)
安全令牌服务 (STS) 是用于根据 WS-Trust 和 WS-Federation 协议构建、签署和颁发安全令牌的服务组件。实施这些协议需要进行大量的工作，但 WIF 能为您完成所有这些工作，让那些不精通协议的人很容易即可启动并运行 STS。 您可以使用云 STS (如 LiveID STS)、预先构建的 STS (如 Active Directory Federation Service (AD FS) 2.0)，或者如果想要颁发自定义令牌或提供自定义身份验证或授权，则可以使用 WIF 构建自己的自定义 STS。借助 WIF 即可轻松地构建自己的 STS。
安全令牌服务允许进一步合并安全逻辑的工具。STS 的典型任务是验证用户，随后创建可以包含声明的安全令牌。客户端必须首先使用 STS 进行验证，然后将返回的令牌转发到客户端希望进行通信的服务。
因为 STS 了解服务 (该信息是令牌请求的一部分)，所以它可以进行集中授权并预先生成服务所需的声明。这样声明转换完全不需要在服务端点进行，它可以通过 STS 集中完成。当系统复杂到一定程度时，它可以大幅简化安全基础结构。
当多个信任域联合时，安全令牌服务也是重要的基础结构组件。通过在多个令牌服务间建立信任，您可以跨越服务所能使用的信任边界交换安全令牌。
WCF 具备支持前述方案的自动客户端/服务端，以及编写 STS 所需的所有基类。但正确实现所有 WS-* 相关规范是一项非常复杂的任务。您应该购买商业 STS 或使用更高级别的工具包 (例如：Zermatt) 编写自定义规范。即将面世的 Microsoft Active Directory 联合身份验证服务版本旨在为 WCF 提供功能完备的 STS。
------------------------------------------------------
附注：名词解释 2
http://msdn.microsoft.com/en-us/security/aa570351.aspx [11]
http://www.microsoft.com/windowsserver2008/en/us/ad-fs-2-overview.aspx
Active Directory Federation Services 2.0 (ADFS 2.0)
Active Directory Federation Services 2.0 是对于 Active Directory 的一个新拓展，它使得 Active Directory 成为了对于那些具有声明意识的应用程序的基础设施。 通过 Security Token Service (STS), AD FS 2.0 使得 Active Directory的用户可以验证那些具有声明意识的应用程序，并为担当关于那些用户的声明 (属性) 的“权威人士”，无论用户信息储存于 Active Directory, SQL数据库，还是其他存储。作为一个联合服务，AD FS 2.0 提供了为联合关系的单点管理。使用例如 SAML 2.0 此类的工业标准协议，可以实现从合作伙伴组织或云端，Active Directory 用户的单点登陆。
开发者可同时使用 ACS、WIF，以及 AD FS v2 来开发网络服务，其结合了 Active Directory 安全性与功能性，灵活性，定制的访问控制规则，简便的紧密结合的开发体验。
原文标题：WCF 4 安全性和 WIF 简介
链接：http://www.cnblogs.com/WizardWu/archive/2010/10/04/1841793.html
【编辑推荐】
