跨域SSO的实现之一：架构设计翻译自CodeProject网站ASP.NET9月份最佳文章：SingleSignOn(SSO)forcross-domainASP.NETapplications。翻译不妥之处还望大家多多指导、相互交流。文章分为两部分：架构设计和程序实现，此为第一篇即：架构设计或者叫设计蓝图（Part-I-Thedesignblueprint）。:)简介周一的早晨，当你正在纳闷周末咋就一眨眼过去了并对接下来漫长的一周感到无比蛋疼之时，你收到了一份Email。操蛋的是它既不是微软的offer也不是Google的offer，而是客户发来的一个新需求。他说你们现在帮我们公司做了很多的ASP.NET的网站和忽悠我们上线的各种系统，现在我想要我的客户只要在我们拥有的任何一个网站上登录一次，那么在我所有的网站上该用户就都已经登录了，同样，随便他从哪个网站上注销掉，那么他也就从我们所有的网站上注销了......你受不了客户这么罗嗦了，心想不就是要一个SSO功能吗？使用ASP.NET的formauthentication不就可以实现了？因为这样可以在同域的不用网站下共享cookie，只需要在machineKey设置一样的配置节就可以了。放狗一搜，果然有xxxx条结果。放狗找东西可是我们程序员的特长。开工前，你又扫了一眼邮件，等等，你看到了邮件中的一行话，微微一蛋疼：我们部署了那些网站，但不是都在同一个域名下。你的客户狠狠地给你来了个下马威，好像他早就放狗搜过，因为cookie不能跨域共享，也就不能用来实现跨域验证了。这到底是神马一回事情！（和老外一样扯玩淡，下面正经些）ASP.NET中的验证原理这个问题可能是老生常谈了，但在解决难题之前，还是先回归基础来看一看事物的本质到底是如何的。因此，我们重温一下ASP.NET表单验证的原理也并不坏。下面是ASP.NET表单验证的流程图验证流程1：你访问一个需要用户验证的ASP.NET页面2：在此请求中ASP.NET运行时开始查找cookie(由于表单验证的cookie)，如果没有查找到，那么将跳转到登录页面(登录页地址配置在了web.config文件中)3：在登录页面中，你提供了相关的验证凭证并点击了登录按钮，系统和已存储的数据对比验证成功后，将Thread.CurrentPrincipal.Identity.Name的属性值设置成了你提供的用户名，并在Response中写入了cookie(同时还写入了用户信息和一些如cookie名，失效日期等)，并重定向到登录前的页面。4：当你再点击其他的页面(或者点击导航到其他的页面)，浏览器发送验证的cookie(也可能包含在该网站下写入的一些其他cookie)，这一次已经包含了在上一次response中上次验证获取到的cookie。5：和以前一样，ASP.NET运行时在请求中查找验证的cookie，这一次找到了，接下来做一些检查(如失效日期、路径等等)，如果还没有失效，那么读取出它的值，恢复出用户的信息，将Thread.CurrentPrincipal.Identity.Name的属性值设置成恢复出的用户名，检查该用户是否有权限去访问当前请求的页面，如果有，那么页面执行的结果返回到用户的浏览器。过程很简单，对吗？ASP.NET中多站点同域下的验证原理如前所述，ASP.NET表单验证完全依赖于cookie。那么只要使得不同的站点共享同样的验证cookie，那么就可以实现在一个站点登录实现所有站点的登录。HTTP协议指出，如果两个站点是同域(或者是子域)的，那么可以共享cookie。本地的处理是浏览器根据网站的URL存储cookie在本地(磁盘或者内存中)。当你请求接下来的任意页面时，浏览器读取和当前请求的URL匹配的域或子域的cookies，并将此cookies包含在当前的请求中。现在我们假设有下面两个网站：www.mydomain.com/site1www.mydomain.com/site2这两个站点共享同样的主机地址(同样的域mydomain.com和子域www)，且两个站点都被配置成了对用户验证和授权都使用表单验证。假设你已经登录过了站点www.mydomain.com/site1，如前所述，你的浏览器现在对于站点www.mydomain.com/site1已经有了表单验证的cookie。现在你随意访问以www.mydomain.com/site1开头的URL，表单验证的cookie都将被包含在请求被发送。为