`
jacksonren1987
  • 浏览: 36285 次
  • 性别: Icon_minigender_1
  • 来自: 苏州
社区版块
存档分类
最新评论

我对SSO的认知历程-《项目中的.NET》试读之感

阅读更多

 

SSO(单点登录),在开篇之前还是先对这个名词解释一下。SSO的英文全称是Single Sign On,翻译成中文就是单点登录。在大型网站中有很多子应用系统,也是由不同团队开发的,整合起来如果要用户每换个应用就要登录次,不仅繁琐也大大降低了用户体验。单点登录就是为这样一个情况而设计存在的,即使用户只需要登录一次,就获得了所有系统的访问权,从而实现单点登录。

 

解释告一段落,我顺着这个话题聊聊我对单点登录的认知过程。第一次接触类似这个情况,是在我刚工作不久的时候。那时候也是刚刚接触,恰好部门里接到一个任务,就是要将几个不同应用(我在本文就按照《项目中的.net》一书中以“论坛、博客、相册”为例说明)整合起来,成为一个系统。

由于这个系统是内部的,所以老大就把这个任务单独的交给我来完成,并没给我任何指导。当时的我根本不了解什么企业应用集成,更不可能知道SSO是什么,所以我的解决办法是一个很傻的办法,现在想来也是让我自己啼笑皆非的办法。

我没有重新设计数据库,而是让一次注册可以成功同时注册三个系统的三个相同账户,当登录了一个系统之后,我就把用户名加密放在session里保存。当用户跨入到另一个系统,我就从session读出这个用户名,查询是否在该系统存在,如果存在,则表示此系统也登录成功,发送令牌并继续把其放在session里。

后来发觉这个用户的数据库太傻了,就把三个表合并成了一个表,并且还为此洋洋得意了很久。

上面就是我第一次去尝试设计应用集成的解决方案,或许算是一种不成熟的单点登录实践吧。

 

之后第二次接触是在外包的时候,客户要求把最近给他做的几个系统给结合起来,变成一个大的类似门户的东西。这时候的我已经学习了不少,也算是刚刚知道单点登录这种解决方案,但是无奈网上的资料只是让我对概念耳熟能详,但大部分是互相转载,描述也很走马观花,不够详尽。在跟几个同样外包过来的同事讨论以后,我们采用了这样一种方法。以a系统(论坛)为主站,b系统(博客)、c系统(相册)都为分站。登录模块完全是在主站上。用户如果登录,无论从abc都跳转到主站去登录,验证后产生主站凭证,此时跳转回登录的系统,产生令牌。此时该分站检测到用户已持有令牌,就用令牌再次去主站获取凭证,成功后授权,同时产生该分站的本地凭证。当用户需要验证时候就去先检查本地凭证。

刚才是说到登录,那么如果是从一个分站b跳转到另一个分站c呢。因为用户在分站b已经有了令牌,那么分站c就用这个令牌去主站获取用户凭证,获取成功以后允许用户访问。同时产生分站c的本地凭证。

这样一个解决方案比原来复杂,但是考虑的已经相对周全,只是有一个问题,就是对主站a系统的压力很大,由于a系统本身具有自己的功能,所以承担了很大的压力,性能上无法保障。

 

今天看到了《项目中的.net》这本书的样章,也是介绍单点登录的。仔细的学习了一遍,这个问题我也在网上查过不少资料,个人觉得本书中对这部分的介绍算是比较全面的。它与我上一次解决该问题时最大的优化就是提取出service认证中心,由认证中心作为所谓主站来承担压力,所有的系统都作为分站执行。具体的流程我不再详细说明,下边这个图比较完整的介绍了整个认证流程:


                                       

除了业务逻辑和流程上的指导,样章中也详细介绍了安全验证、接口设计、数据库设计等各方面内容,让我对单点登录的整体设计有了更加深入的了解。

 

随着互联网应用的增多,门户网站也越来越多,类似的单点登录应用将会成为很迫切的需求。上面我自己三次接触单点登录的经理,意义不只是在于解决方案的学习了解、知识能力的提高,也记录了我自己成长的历程,获益匪浅。

 

  • 大小: 45.6 KB
0
0
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics