走在架构师的大道上 Jack.Wang's home

Java, C++, linux c, C#.net 技术,软件架构,领域建模,IT 项目管理 Dict.CN 在线词典, 英语学习, 在线翻译

BlogJava 首页 新随笔 联系 聚合 管理
  195 Posts :: 3 Stories :: 728 Comments :: 0 Trackbacks

        最近好多朋友问我关于 SSO 的问题,其实市面上有很多成型的产品,SSO 理论本身也提了好多年了,下面是我以前写的一篇文章《基于 Web 的单点登录理论研究》里的一部分关于跨域和票据设计问题,相信对问我的朋友们有些帮助。
 

早在上个世纪中期,SSO技术就已备雏型了,后来一些大公司用驱动技术或者屏幕截取技术把 windows 认证信息传递到自己的应用系统中,避免用户再次登陆。直到 1998年,SSO技术日趋成熟,他们已经建立了独立的SSO系统,这些系统能够透明的把OS 认证信息传递给上层的应用系统,为后来 SSO 系统打下了良好的基础。

随着互联网技术的不断发展,互联网应用的复杂度越来越高,SSO技术也从原来只在C/S应用程序下使用,发展到了B/S应用系统。所以SSO系统构建的复杂性也越来越大。随着XML,WEB SERVICE等一些跨平台,跨语言的技术产生和应用,以及相关的一些标准和规范的发布和使用,比如 SAML(Security Assertion Markup Language,安全断言标记语言)等为异构系统的通讯提供了一个较好的平台,共同构成现代网络的必备条件。目前业界基本上构成两大阵营,OASIS/Liberty与WS-*,即SAML2.0与WS-Federation,两者有些地方是重复的,未来统一的单一标准究竟是以哪个为基础,还没有定论,或许会建立在二者之上。

近年来,身份认证系统发展的很快,已经逐渐由传统的多点登录向集中式单点登录方向发展,同时身份也不仅仅局限在一个公司内,公司之间的联合身份认证已很热门,联合身份认证解决如何在公司之间实现单点登录,涉及到多个身份认证服务器互联和信任问题。

目前业界已有很多门户产品支持 SSO如 IBM 的 WebSphere,BEA 的 WebLogic 和 Apache 的 Tomcat 等等;也有不少成功的商业软件,如微软的 Passport, Netegrity 的 Siteminder,Novell 公司的 iChain,RSA 公司的 ClearTrust 以及 USBKey 的方式等等;开源的也有很多,如耶鲁大学开发的 CAS,Sun 的 OpenSSO 等等;当然互联网上也有不少的资料但各家 SSO 产品的实现方式也不尽相同,对客户的要求比较严格,较难应用到自己的系统中,所以很多公司都有自己的单点登录平台。

3 单点登录机制
单点登录的机制其实是很简单的,现实中也不乏这样的例子,比如你去景点游玩,里面有“过山车”,“百鸟园”,“划船”等等项目,游客可以在各自的项目点买票,如果游客期望游玩所有的项目,这种买票方式需要游客在每个项目点排队,很不方便,而且钱包掏来掏去,也不安全。因此绝大部分游客都选择买一套票,就可玩遍所有的项目而不需要多余的排队,只需在每个项目入口出示一下套票就可游玩。
单点登录的机制也是一样地,如图1:
 
    
当用户第一次访问 ERP系统的时候,因为还没有登录,就被引导到认证中心进行登录(1);根据用户登录信息,认证中心进行身份验证,如果通过,就返回一票据(ticket)给用户(2);用户再访问其他应用系统的时候(3,5)就会带上这个票据,作为自己认证的凭据,应用系统接受到请求之后会把ticket送到认证中心进行效验,检查ticket的是否合法(4,6)。如果通过效验,用户不需要重新登陆就可访问EFP系统和EIP系统了,即”一次登录,多方认证[2]”。
     要实现单点登录,就要统一认证机制,认证中心的主要功能是用户登录认证,票据生成和票据有效性检查。所有加入认证中心的系统都不能解析票据信息(要想获得用户信息,认证中心有功能提供),而是通过与认证中心的通信来判断当前用户是否登录过,从而完成单点登录的功能。
     用户信息的格式、命名与存储方式多种多样,针对目前各个系统用户信息很难整合的情况,应该允许存储在不同的地方或以不同的方式存储(比如数据库,LDAP, 文件或者网络来源) 如图2。
 


实际上,只要有统一的认证中心,统一的票据,无论用户信息来源哪里都可实现单点登录机制。
当然,认证中心也不一定唯一,比如联合登录,如图3。

 
这就需要不同的认证中心之间可共享票据和互通验证信息。实现更高一级别的单点登录系统,目前已有几种联合认证的 XML 标准[4], 包括安全声明标记语言( SAML),自由联盟( Liberty Alliance) 计划和Web 服务联盟语言( WS-Federation) 。


1   跨域和票据设计

1.1   跨域设计

单点登录机制中,比较核心的数据结构就是票据,票据本身的实现下一小节介绍,由于这篇论文针对的是 Web 应用系统,所以客户端一般用的是浏览器,如果让浏览器保存票据,那只能借助 Cookie,当然也可采用服务器端 Session 共享票据信息,但本文采用 Cookie 和Session 双存储的方式。

浏览器中最多保存300个cookie;为单个服务器最多只能保存20个;每个不能超过4000个字节,通过 HTTP 协议在浏览器和服务器之间传输,完全满足目前系统认证整合的需求。

理论上,Cookie 是不能跨域访问的,但通过一些技巧也可实现。针对跨域 Cookie 设计这里分两种方式论述:即跨子域和跨域。
1.1.1   跨子域设计

所谓跨子域登录,比如A 站点为a.jmsys.com, B 站点为b.jmsys.com,认证中心站点 C为 c.jmsys.com。从三个站点的关系可以看出,他们都属于同一个二级域 jmsys.com,不同的是子域不同,一个为a,一个为b,一个是c. 他们统一的平台域名为 www.jmsys.com

    Cookie 本身是不能跨域的,即 A, B 站点读不到C 站点写的 cookie 信息,解决办法很简单,将 cookie 的 domain 属性设置为二级域 即Cookie. domain=".jmsys.com",那么 C 写的 cookie 信息 A, B都能读到。当认证中心产生票据时,以 Cookie 的方式存于浏览器端,A,B都能通过 Cookie 得到票据,可简单实现单点登录机制。

1.1.2    跨异域设计

所谓跨子域登录,比如A 站点为a.jmsys.com, B 站点为b.jmsys.com,认证中心站点 C为 c.jmsys.com。从三个站点的关系可以看出,他们都属于同一个二级域 jmsys.com,不同的是子域不同,一个为a,一个为b,一个是c. 他们统一的平台域名为 www.jmsys.com

    Cookie 本身是不能跨域的,即 A, B 站点读不到C 站点写的 cookie 信息,解决办法很简单,将 cookie 的 domain 属性设置为二级域即Cookie. domain=".jmsys.com",那么 C 写的 cookie 信息 A, B都能读到。当认证中心产生票据时,以 Cookie 的方式存于浏览器端,A,B都能通过 Cookie 得到票据,可简单实现单点登录机制。

完全跨域登录[3],是指A,B站点和C站点没有共同的父域,比如A站点为a.jmsys1.com,B站点为b.jmsys2.com,由于这种情况票据较复杂,这里暂时把C站点(c.jmsys3.com)创建的ticket叫做C-ticket,而A站点创建的叫A-ticket,B的为B-ticket. 这种情况每个站点都要有创建 Cookie 的能力,其实就是 C-ticket 的复制,当然也有其他的方式达到这种效果,如图4
          
        由于A 站点(a.jmsys1.com)不能读取到由C站点(c.jmsys3.com)创建的票据,所以当用户访问A站点时,首先查看是否有A-ticket,如果没有,证明用户没有在A站点登录过,不过并不保证用户没有在B站点登录,请求被重定向到C 站点,C读取C-ticket,如果没有,就需要重定向登录页面,登录页面完成登录后,写一个加密cookie,也就是C-ticket,并且重定向到A站点,并把 ticket作为参数传递过去,A 站点也要写一个cookie,也就是A-ticket,今后用户再次访问A站点时,只需要检查这个A-ticket 是否存即可。当用户访问B站点时,会重复上述过程。

     注销时需要删除C-ticket 。只要 C-ticket 在认证中心清除了,用户访问任何一个站点都需要重新登录。

  1.2   票据设计

票据以 Cookie 为载体,采用数字签名技术和 RSA 算法。认证中心产生自己的公钥和私钥,每次生成票据时对其签名。客户端请求验证时,认证中心会用其公钥和会话密钥验证票据,保证票据的机密性、完整性和签发方身份的不可否认性。

当 RSA 算法的密钥长度为1024bit时,需要1012 MIPS(100 万次/s运算的计算机工作一年)年才能解开[1],而且认证中心也会为每个票据生成会话密钥,加密 ticket。所以票据是比较安全的。

Ticket={VER,AL,UserID,ValidDate,other,[hash(VER,AL,UserID,ValidDate,other)]Sign}

其中,VER是票据的版本号,AL是算法的标识(如 RSA, MD5等),UserID是用户编号,ValidDate 是票据的有效截至日期,other是指其他信息,hash()是单向散列函数(如MD5SHA等),[]Sign是对[]中的数据的签名值,认证中心成为安全域的信任端。各应用系统不能解密票据信息,只能简单的把票据传给认证中心,由认证中心对票据解析验证,并做相关日志记录(以备行为追踪和统计用)。





本博客为学习交流用,凡未注明引用的均为本人作品,转载请注明出处,如有版权问题请及时通知。由于博客时间仓促,错误之处敬请谅解,有任何意见可给我留言,愿共同学习进步。
posted on 2008-09-15 18:43 Jack.Wang 阅读(6115) 评论(4)  编辑  收藏 所属分类: 开发技术架构师篇计算机论文

Feedback

# re: 基于 Web 的单点登录理论研究之跨域和票据设计[未登录] 2008-09-16 13:50 Hank
早在"上个世纪"中期,SSO技术就已备雏型了,一些大公司用驱动技术或者屏幕截取技术把 windows......

faint. "上个世纪"?? century or decade?  回复  更多评论
  

# re: 基于 Web 的单点登录理论研究之跨域和票据设计 2008-09-18 13:08 antisaas
好文!  回复  更多评论
  

# re: 基于 Web 的单点登录理论研究之跨域和票据设计 2011-11-18 13:59 徐霞客
不论你用多么复杂的算法生成 Ticket, 都不能保证这个Ticket不被窃取
如果这个Ticket 要跨域传递,作为认证的依据,那必然有可能被窃取,
一旦被截获,就可以被第三方未经用户名和口令认证即可登录到相关的业务系统
即使限定这个Ticket的时效性,也仅仅是降低了被截获的可能性。
如果这个Ticket是跟客户端是正关联性的。除非CS程序,可以保证这个Ticket与客户端具有很强的正关联性(例如CPU ID,MAC ADDRESS),但是BS无法得到这个客户端的唯一标识的。  回复  更多评论
  

# re: 基于 Web 的单点登录理论研究之跨域和票据设计 2013-04-08 16:31 chtang
由于A 站点(a.jmsys1.com)不能读取到由C站点(c.jmsys3.com)创建的票据,所以当用户访问A站点时,首先查看是否有A-ticket,如果没有,证明用户没有在A站点登录过,不过并不保证用户没有在B站点登录,请求被重定向到C 站点,C读取C-ticket
请问A站点如何读取用户在B站点登录后生产的C-ticket?  回复  更多评论
  


只有注册用户登录后才能发表评论。


网站导航: