您的位置:知识库 » .NET技术

跨域SSO的实现之一:架构设计

作者: Parry  来源: 博客园  发布时间: 2010-11-02 15:02  阅读: 9457 次  推荐: 3   原文链接   [收藏]  
摘要:翻译自CodeProject网站ASP.NET9月份最佳文章,文章分为两部分:架构设计和程序实现,此为第一篇即:架构设计或者叫设计蓝图(Part-I - The design blue print)。:)
[1] 跨域SSO的实现之一:架构设计
[2] 跨域SSO的实现之一:架构设计

操作流程:

 

  请求http://www.domain1.com/中一个需要验证的页面

状态:浏览器没有验证cookie

  浏览器发送一个请求到http://www.domain1.com/,但请求中没有验证cookie(因为还没有属于http://www.domain1.com/的cookie)。

状态:浏览器没有验证cookie

  因为请求中没有验证cookie,所以请求http://www.domain1.com/的登录页面

状态:浏览器没有验证cookie

  用户提供登录凭证点击登录按钮,浏览器发送一个POST请求到http://www.domain1.com/
http://www.domain1.com/验证用户提供的登录凭证,验证通过后,标记用户的状态为已登录,添加验证的cookie和其他的用户信息一起添加在response中

状态:浏览器没有验证cookie

  response并没有返回给浏览器,而是将请求重定向到http://www.domain2.com/的一个页面,并将ReturnUrl设置成重定向前http://www.domain1.com/的URL值。在验证cookie被包含在了response中了后,cookie被发送给浏览器。

状态:浏览器没有验证cookie

  浏览器接收到了包含验证cookie的response和重定向到http://www.domain2.com/的命令。浏览器存储了http://www.domain2.com/的验证cookie并向http://www.domain2.com/发送请求。

http://www.domain2.com/立即再重定向到存储在ReturnUrl中的URL地址,在此请求中读取cookie值并为http://www.domain1.com/设置验证cookie。最终,在重定向的命令中也包含了这些验证cookie。

状态:浏览器包含了http://www.domain2.com/的验证cookie

  浏览器接收到包含了验证cookie的重定向命令跳转到http://www.domain1.com/。现在浏览器存储了站点1的验证cookie并开始请求站点1,当然在请求中包含了验证cookie。

状态:浏览器包含了http://www.domain1.com/和http://www.domain2.com/的验证cookie

  站点1检查了请求中包含了验证cookie,就不需要再去跳转到验证页面去验证,而是返回用户请求的页面

状态:浏览器包含了http://www.domain1.com/和http://www.domain2.com/的验证cookie

  如果此时用户请求站点2, 因为浏览器已经存储了站点2的验证cookie,cookie将被包含在请求中,站点2从cookie中获取到用户信息,并为此用户返回请求的页面。
  当浏览器验证了站点2和站点3后,那么用户就已经登录了所有的站点,这样就完成了一次单点登录。

  如何单点注销?

  作为单点登录的一部分,我们还需要去关注下单点注销,就是说当用户在一个站点注销后,那么就认为他从所有的站点都注销了。
  清除所有站点的cookie和上面登录一样,也是请求-重定向-返回的过程。只是和设置验证cookie不一样的是,这次从response中移除验证cookie。

  此单点登录模型的缺点

  这个模型在两个站点上还是能运行的很好的。从一个站点登录或注销,此SSO模型下的站点都将遵从请求-重定向-返回的流程。当用户登录任一页面时,因为已经存储了所有站点的验证cookie,那么就不需要再执行上面的那个循环的流程了。
  但是当站点超过两个时,问题就变得复杂了,当登录站点1时,程序将重定向到站点2和站点3进行验证cookie的设置,最后站点3在跳转到站点1,服务器返回用户请求的页面。这使得每个站点的登录和注销的过程变得复杂并花费较高的代价。如何超过3个站点呢?如果这样去设计20+站点的单点登录呢?这个模型将完全不能胜任了。
  并且此模型需要每个站点都具备用户验证逻辑,因为需要来请求此站点并设置其验证cookie。
  因此此模型丢失了一般意义上的单点登录的概念,我们需要一个更好一点的模型去实现单点登录的功能。

  更好的跨域单点登录架构

  前面提到的架构中,设置移除cookie都需要跳转到N-1个站点去完成。每个站点还需要知道N-1个站点复杂的登录注销逻辑,如果我们为所有的站点只去维护一份验证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,原始站点检查用户令牌正确后返回用户请求的页面。

  传输代价

  场景1:访问公共页面
  从浏览器到站点+站点到浏览器
  1请求+1返回
  场景2:访问一个需要验证的页
  从浏览器到站点+重定向到sso站点(检查cookie)+重定向到原站点(没有cookie)+原站点返回登录页面到浏览器
  1请求+2跳转+1返回
  场景3:登录
  浏览器POST到站点+调用验证服务进行用户验证+浏览器跳转到SSO站点(带有令牌)+重定向到原站点(带有验证cookie)+通用服务验证令牌+返回用户请求的需要验证的页面
  1请求+2验证服务调用+2跳转+1返回
  场景4:登录后请求一个需要验证的页面
  请求站点+向SSO站点跳转验证cookie(带有验证cookie)+跳转到原站点(检查验证cookie)+调用服务验证令牌+返回请求页面
  1请求+2跳转+1服务请求+1返回
  场景5:注销
  请求站点进行注销+请求SSO站点进行注销+请求原站点移除验证cookie+返回
  1请求+2跳转+1返回

  孰是孰非

  比较这两种架构,第一中架构更适合两个站点,最多三个站点,虽然需要部署复杂冗余的验证逻辑,但是随后的页面请求中就是普通的页面请求了(1请求+1返回)。
  第一种架构不易于扩展,且会冗余出很多的用户验证逻辑。
  而第二种架构,不管有多少个需要进行单点登录的网站,也不需要其他网站参与此过程,验证的cookie只有sso站点管理,这样的架构逻辑清晰、易扩且部署方便。
  然而有一些性能的问题,不同于第一种架构,这种架构当用户请求一个需要验证的页面时需要请求三次(请求sso站点和原站点,两次请求是内部的跳转),且多的两次请求花费的时间很少(空跳转请求,用于设置和检查cookie),在如今这样的网络环境下是可以接受的。

  第二种架构的程序实现

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

程序实现源码下载

[第1页][第2页]
3
1
标签:ASP.NET SSO

.NET技术热门文章

    .NET技术最新文章

      最新新闻

        热门新闻