基于 web 的单点登录理论研究之跨域和票据设计 -凯发k8网页登录

        最近好多朋友问我关于 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. 他们统一的平台域名为 。

    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. 他们统一的平台域名为 。

    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()是单向散列函数（如md5、sha等），[]sign是对[]中的数据的签名值，认证中心成为安全域的信任端。各应用系统不能解密票据信息，只能简单的把票据传给认证中心，由认证中心对票据解析验证，并做相关日志记录（以备行为追踪和统计用）。