介绍 WS-Federation 一： 让Passport和传统SSO见鬼去吧！

 

微软在过去的身份验证服务上，一直采用的Passport验证，但已经是N年前推出来的一个软件架构，当然也被软件界很多地方采用到，由于很多安全问题以及隐私问题，导致05年eBay与Passport分手，相继不少公司也与微软身份验证服务分道扬镳。为何会这样呢？这还得从Passport流程说起：

Passport 是基于 Cookie 的身份验证服务。使用 Passport 身份验证的示例事务对话的工作方式如下：

1. 客户端向受到保护的资源（如 http://www.contoso.com/default.aspx）发出 HTTP GET 请求。
2. 检查客户的 Cookie 是否具有现有的 Passport 身份验证票。如果站点找到有效的凭据，则站点对该客户进行身份验证。如果请求不包括有效的身份验证票，则服务器返回状态代码 302 并将客户重定向到 Passport 登录服务。响应在查询字符串中包含一个 URL，该 URL 被发送到 Passport 登录服务以便将客户定向回原始站点。
3. 客户端执行重定向操作，再向 Passport 登录服务器发出 HTTP GET 请求，然后传输来自原始站点的查询字符串信息。
4. Passport 登录服务器向客户提供登录窗体。
5. 客户端填写窗体，并使用安全套接字层 (SSL) 将 POST 发送回登录服务器。
6. 登录服务器对用户进行身份验证并将客户重定向回原始 URL (http://www.contoso.com/default.aspx)。响应在查询字符串中包含一个加密的 Passport Cookie。
7. 客户遵循重定向并再次请求原始的受保护资源，这一次使用 Passport Cookie。
8. 起始服务器上的 PassportAuthenticationModule 会检测是否存在 Passport Cookie，并测试身份验证。如果成功，则该请求通过身份验证。

这个流程简单的绘制如下：

大家会发现，如果要使用Passport服务，那么你的用户的用户凭据必须存储在Passport服务器上。这个是敏感的数据哦！如果微软有个什么内鬼的话……………..

另外，这种安全是基于的对称加密的tripleDES算法的，对称算法可以基于穷举破解的。当然还有HTTPS证书机制保证用户的凭证不会在传输时截获并解密。

基于现有的互联网发展情况来看，有很多类似这种机制，许多相对独立的网站，他们拥有各自的用户资源，和和各自的资源优势，都希望自己的用户能够享受其他网站的特殊服务，又能够让其他网站的用户消费自己的特殊服务。传统的SSO，就是这样实现的。比如互联星空的，SP的服务都是受保护资源，用户在登录了互联星空后，才可以获得验证票据，在各个接入的SP内消费。给用户带来的好处就是只要登录互联星空，就能消费N多的SP服务。

当然我们举的例子是互联星空和SP的模型，他们之间只能是强弱之间的对话，没有挣扎的能力。那如果是谷歌和百度之间用户之间需要交流怎么办？到底是 把百度的用户名密码存储到谷歌上，还是将谷歌的用户名密码存储到百度上呢？？？

敬请期待下篇：

把百度和谷歌和谐起来！