最近好多朋友问我关于 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。
这就需要不同的认证中心之间可共享票据和互通验证信息。实现更高一级别的单点登录系统，目前已有几种联合认证的 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()是单向散列函数（如MD5、SHA等），[]Sign是对[]中的数据的签名值，认证中心成为安全域的信任端。各应用系统不能解密票据信息，只能简单的把票据传给认证中心，由认证中心对票据解析验证，并做相关日志记录（以备行为追踪和统计用）。
本文转自BlogJava 新浪blog的博客，原文链接：基于 Web 的单点登录理论研究之跨域和票据设计，如需转载请自行联系原博主。
