SSO 跨域单点登录架构

跨域单点登录架构

如果我们为所有的站点只去维护一份验证cookie呢？使用一个独立的站点去完成验证用户并设置验证cookie的工作呢？这个想法好像不错。
要使用单点登录，那么就需要用户的数据是统一的，这样的话就可以通过一个站点提供web或者WCF服务来完成验证和授权的功能。这样就省去了冗余的用户验证逻辑，现在最重要的是这个独立的站点如何在SSO架构中起作用。
在这个架构模型中，浏览器不存储任何其他站点的验证cookie，只存那个独立站点的验证cookie，我们就给它起名叫http://www.sso.com/。
在此架构中，对每一个站点的请求都将被直接跳转到http://www.sso.com/，由于检查验证cookie是否存在。如果cookie存在，如果存在，返回请求的页面，如果不存在，那么就跳转到对应的登录页面。
大致流程图如下：

                       

便于理解，我们假定有下面两个网站：
http://www.domain1.com/
http://www.domain2.com/
还有一个用于管理验证cookie的站点：http://www.sso.com/。

 

验证流程如下：

 

用户请求http://www.domain1.com/中一个需要验证的页面
重定向到http://www.sso.com/，ReturnUrl参数设置成请求站点1时的URL。
 http://www.sso.com/检查是否有验证cookie存在，如果在请求中没有任何用户令牌存在，那么请求中带着用户需要登录的指令就跳转到站点1。在query string中仍然保留着之前ReturnUrl参数的值。
站点1从参数中得知是从http://www.sso.com/跳转而来，且得知没有用户验证cookie，最后跳转到站点1的登录页面进行登录，而不跳转到http://www.sso.com/。

用户提供验证信息点击登录按钮，请求没有回置到站点http://www.sso.com/，这时，站点1通过http://www.sso.com/提供的web/WCF接口进行用户的验证，如果验证成功，那么为用户颁发一个令牌(可以是一个GUID)。
站点1标志用户已经登录成功（在session中存储用户对象），一个包含了令牌的URL跳转到http://www.sso.com/设置验证cookie，ReturnUrl参数还是设置成前面请求的URL。
http://www.sso.com/站点检查过来的URL，发现有用户令牌，但还没有用户验证cookie，说明已经通过了站点1的认证，现在需要设置站点http://www.sso.com/下的验证cookie。照例设置好了cookie后，将cookie添加在response中，还添加上用户令牌按照ReturnUrl参数中的URL一并返回。
浏览器得知要跳转到站点1，并且有了站点http://www.sso.com/的验证cookie，在本地存储下sso站点的验证cookie并对站点1发起请求。
站点1检查了用户令牌，因为是通过站点SSO的web/WCF服务验证并通过的，所以站点1返回用户请求的页面。

现在用户请求站点2
浏览器跳转到sso站点，依然设置好ReturnUrl的值。
浏览器因为要跳转到sso站点，发现本地有了sso站点的验证cookie，所以将cookie添加在请求中一并发出。
sso站点检查cookie，发现cookie还没有过期，那么在query string中添加上用户令牌按照ReturnUrl返回。
站点2发现有用户令牌，证明已经走过验证流程，那么就返回用户请求的页面。

总结

刚开始，浏览器没有任何http://www.sso.com/站点下的验证cookie。请求站点1和站点2任何需要验证的页面(需要内部的跳转到sso站点检查验证cookie是否存在)。用户登录后，sso站点的验证cookie存储在本地（重要的是用户令牌仅仅用户用户登录会话时）。
现在请求站点1或者站点2都跳转到sso站点，浏览器发送sso站点的验证cookie并检查用户令牌，验证后再跳转到原始请求的URL，原始站点检查用户令牌正确后返回用户请求的页面。

第二种架构的程序实现

等有空了来翻译完第二部分：程序实现
等不及的朋友可以先看原文：http://www.codeproject.com/KB/aspnet/CrossDomainSSOExample.aspx