本文来自网易云社区
单点登录（Single Sign On），简称为 SSO，目前已经被大家所熟知。简单的说, 就是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。 举例: 我们可以使用corp邮箱的账号登录oa系统; 登录了网易通行证，就能够轻松在邮箱，云音乐等应用中来回切换，而不需要每次都输入账号/密码。SSO的解决方案，有我们非常熟悉的OpenID，和本文准备介绍的WS-Federation，以及其他SAML，CAS等等。
WS-Federation（简称: WS-Fed）属于Web Services Security(简称: WS-Security、WSS: 针对web-service安全性方面扩展的协议标准集合) 的一部分，是由OASIS（https://www.oasis-open.org）发布的标准协议，其主要贡献者是Microsoft 和 IBM。WS-Fed 1.1 版本发布于2003年, 最新的1.2版本标准发布于2009年。 所以这协议不是个新鲜玩意，而是个老家伙（OpenID是在2005年才开发了第一个版本）。只不过该协议主要应用在企业服务，并且是在微软自己的产品中主推，其他厂家的产品可能更愿意选择SAML。另外，该标准是基于SOAP的，整个协议虽然功能强大，细节考虑周全，但实现起来会比较重，只有为了能和微软的服务整合，才会优先考虑该协议。
WS-Federation的基本目标就是为了能够简化联合（所谓联合: Federation，是指一组相互之间存在安全共享资源关系的领域集合）服务的开发。WS-Fed使用了原有的WS-Security框架，WS-Trust和WS-SecurityPolicy。WS-Security框架提供了如何基于安全令牌的SOAP消息传输机制；WS-Trust定义了Security Token Service （STS）协议用于请求/发布安全令牌；WS-SecurityPolicy允许具体的应用服务描述它们各自的安全需求。WS-Federation 拥有以下扩展特性:
Ø Federation Metadata
当一个组织需要连接到一个已存在的联合时，这些联合的成员就需要把相关服务的配置信息公布出来并互相交换。从而使得联合中的成员都能够识别那些共用的服务（例如Identity服务），还有那些用来访问服务的策略信息。为此WS-Fed定义了元数据模型和文档格式用于这些相关服务的发现和结合，以此产生的联合元数据文档(Federation Metadata Document)描述了服务是如何参与到联合中，并如何被其他服务调用。
Ø Authorization
WS-Fed中定义的授权模型不仅能够满足基本的联合内不同服务间基本的通用授权需求。额外增加了2个扩展特性用于丰富授权功能:
a) 允许在发往STS的RST请求中可以附加一个关于当前令牌请求的环境信息
b) 允许在处理不同的具体请求中声明不同的具体要求。
Ø Authentication Types
WS-Fed为常用的认证方式和保证级别定义了一套通用资源标识符（URI），可以在RST和RSTR消息的wst:AuthenticationType参数中直接使用，从而方便联合内服务之间的交互。
Ø Attribute Services
当请求者在访问某些资源时，可能会被要求提供一些额外信息用于完成访问授权。但这些信息又没有包含在STS颁发的令牌中。因此，属性服务就可以用于解决此类常见问题，它可以让请求者在必要的时候来获取到当前账号的额外信息，从而完成后继的资源访问授权。WS-Fed中定义了一个基于STS概念的属性服务访问模型
Ø Pseudonym Services
通过笔名服务可以使得不同的联合服务获取到的是不同的笔名身份信息，从而降低身份诈骗的安全风险。 WS-Fed描述了笔名服务如何透明地STS整合，从而自动地将笔名映射到所颁发的实际安全令牌。
Ø Privacy
WS-Fed扩展了RST/RSTR语法，定义了请求者如何声明其隐私要求 以及 STS在颁发安全令牌时如何声明隐私机制已经被启用。通过隐私机制，当请求者向具体服务发起请求时，就可以附带上相关个人/组织的隐私要求。
Ø Indicating Specific Policy and Metadata
现实中请求者在访问具体服务时，其中的某个请求可能会被要求额外的安全保证。为此WS-Fed定义了该机制，能够通过请求者某个请求需要附加额外的安全语义，并且能够让请求者在碰到类似情况时可以自动重建请求，附加上安全语义后，再次尝试和指定服务通讯。
Ø Federated Sign-Out
WS-Fed定义了联合登出的机制。基于该机制，当某个账号声明登出时，联合中所有参与的服务都能够识别到这个登出动作，从而清理所有相关的登录状态或者安全令牌，进一步提高安全性。
Ø Web (passive) Requestors
由于WS-Trust模型要求应用完全基于SOAP，这个显然会限制使用场景。 WS-Federation为了解决这个问题，扩展了该模型，可以采用HTTP中最基础的机制（GET，POST，重定向，cookie）来封装WS-Trust协议。从而，摆脱了对SOAP的强制依赖。 所有支持HTTP 1.1标准的浏览器 或者 web应用都可以使用上WS-Fed。WS-Fed中称呼该模式为: “WS-Federation Passive Requestor Profile” (相应的, 基于SOAP的就是Active requestor profile)。 该流程也是目前我们最常用的方式，来看一下流程示例:
流程说明:
1. Browser向 SP 发起请求获取资源A
2. SP请求Browser提供认证凭证
3. Browser向IP请求认证凭证
4. Browser 和 IP 进行认证，例如: IP弹出个可供输入账号/密码的窗口，用户输入后上传给IP
5. IP鉴定身份，发布认证凭证 （即，对应第3步的应答）
6. Browser将IP给的凭证发送给SP （即，对应第2步的应答）
7. SP判断凭证合法后，返回资源给Browser （即，对应第1步的应答）
对比一下OpenID的认证流程:
很明显的差异在于: OpenID在认证流程中，RP和OP之间是需要互相通讯的；而WS-Fed中SP和IP之间没有直接的通讯，全部通过Browser转发完成。因此OpenID认证流程必须保证OP能够和所有依赖该OP的应用服务(RP)直接通讯，并且在执行性能上会依赖RP和OP之间的通讯状况。而WS-Fed对IP的保护会更好，只需要保证使用者能够和IP通讯即可，认证性能上也能有更好的保证。此外，WS-Fed协议本身就支持授权机制，并且更多地考虑了企业的应用场景需求；而OpenID只支持认证功能。所以，简单来讲: WS-Fed 更适合企业用户；而OpenID更适合个人用户。
WS-Fed的开源实现比较少，基于Java的就更少。目前能找到实现该协议的有Apache CXF Fediz 和 auth10-java。 前者是一套比较完整的Web Security框架包含应用端和认证服务器端的实现; 后者仅仅是一个可以使用WS-Fed协议进行SSO的应用端模板。
最后，提一下OAuth。OAuth的设计目的是为了解决授权（Authorization）问题，它并不涉及到认证（Authentication）逻辑，与WS-Fed，OpenID有本质的差别。前者的着重点在于“你能做什么”，后者的着重点在于“你是谁”。将OAuth应用于”认证”场景的，本质上都是伪认证，前提是我们假设授权服务只会把资源的权限授予给该资源的拥有者。 目前OpenID已经发展到了OpenID Connect，实质上可以视为Authentication+OAuth2，从而一揽子解决认证和授权问题，并且得到了很多大公司的支持，相信以后会逐步替代单独的OpenID服务。
参考资料
Ø https://msdn.microsoft.com/en-us/library/bb498017.aspx
Ø http://docs.oasis-open.org/ws-sx/ws-trust/200512
Ø https://www.oasis-open.org/standards#wsfedv1.2
Ø https://msdn.microsoft.com/en-us/library/ff423674.aspx
Ø http://cxf.apache.org/fediz.html
Ø https://github.com/auth10/auth10-java
原文： 聊聊WS-Federation
网易云新用户大礼包：https://www.163yun.com/gift
本文来自网易实践者社区，经作者邱晟授权发布。
相关文章：
【推荐】 Amazon新一代云端关系数据库Aurora（下）
【推荐】 行为式验证码的前景
【推荐】 知物由学 | 一文读懂互联网内容审核机制