跨域sso的实现之一：架构设计.docx

翻译自 CodeProject 网站 ASP.NET9 月份最佳文章：Single Sign On (SSO) for cross-domain ASP.NET applicatio ns 。 翻译不妥之处还望大家多多指导、相互交流。 文章分为两部分：架构设计和程序实现，此为第一篇即：架构设计或者叫设计蓝图( Part-I -The design blue print )。:) 简介 周一的早晨，当你正在纳闷周末咋就一眨眼过去了并对接下来漫长的一周感到无比蛋疼之 时，你收到了一份 Email。 操蛋的是它既不是微软的 offer也不是Google的offer，而是客户发来的一个新需求。 他说你们现在帮我们公司做了很多的 ASP.NET的网站和忽悠我们上线的各种系统，现在我 想要我的客户只要在我们拥有的任何一个网站上登录一次， 那么在我所有的网站上该用户就 都已经登录了，同样，随便他从哪个网站上注销掉，那么他也就从我们所有的网站上注销 了 你受不了客户这么罗嗦了，心想不就是要一个 SSO功能吗？使用 ASP.NET的form authentication 不就可以实现了？因为这样可以在同域的不用网站下共享 cookie，只需要在 machineKey设置一样的配置节就可以了。放狗一搜，果然有 xxxx条结果。放狗找东西可 是我们程序员的特长。 开工前，你又扫了一眼邮件，等等，你看到了邮件中的一行话，微微一蛋疼：我们部署了那 些网站，但不是都在同一个域名下。 你的客户狠狠地给你来了个下马威，好像他早就放狗搜过，因为 cookie不能跨域共享，也 就不能用来实现跨域验证了。 这到底是神马一回事情！(和老外一样扯玩淡，下面正经些) ASP.NET 中的验证原理 这个问题可能是老生常谈了， 但在解决难题之前，还是先回归基础来看一看事物的本质到底 是如何的。因此，我们重温一下 ASP.NET表单验证的原理也并不坏。 下面是ASP.NET表单验证的流程图 Sequence Diagram : Forms Authentication 2 :在此请求中 ASP.NET运行时开始查找 cookie（由于表单验证的 cookie），如果没有查找 到，那么将跳转到登录页面（登录页地址配置在了 web.config文件中） 3:在登录页面中，你提供了相关的验证凭证并点击了登录按钮，系统和已存储的数据对比 验证成功后，将 Thread.Curre ntPrin cipal.Ide ntity.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包含在当前的请求中。现在我们假设有下面两个网站: /sitel /site2这两个站点共享同样的主机地址（同样的域 配置成了对用户验证和授权都使用表单验证。 /site1 ， 女口前 所述， 你的 /site1 面时，浏览器读取和当前请求的 URL匹配的域或子域的 cookies，并将此cookies包含在当 前的请求中。 现在我们假设有下面两个网站: /sitel /site2 这两个站点共享同样的主机地址（同样的域 配置成了对用户验证和授权都使用表单验证。 /site1 ， 女口前 所述， 你的 /site1 已经有了表单验证的 cookie 。 和子域www），且两个站点都