聊聊WS-Federation

本文来自网易云社区

单点登陆（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

本文来自网易实践者社区，经做者邱晟受权发布。