SSO单点登录

SSO的实现机制不尽相同，大体分为Cookie机制和Session机制两大类。

• WebLogic通过Session共享认证信息。Session是一种服务器端机制，当客户端访问服务器时，服务器为客户端创建一个惟一的SessionID，以使在整个交互过程中始终保持状态，而交互的信息则可由应用自行指定，因此用Session方式实现SSO，不能在多个浏览器之间实现单点登录，但却可以跨域。
• WebSphere通过Cookie记录认证信息。Cookie是一种客户端机制，它存储的内容主要包括: 名字、值、过期时间、路径和域，路径与域合在一起就构成了Cookie的作用范围，因此用Cookie方式可实现SSO，但域名必须相同。

目前大部分SSO产品采用的是Cookie机制，公司第一个版本的单点登陆系统也是如此，目前能够找到的最好的开源单点登录产品CAS也是采用Cookie机制。 CAS http://www.ja-sig.org/products/cas/，CAS单点登录系统最早由耶鲁大学开发。2004年12月，CAS成为JA-SIG中的一个项目。JA-SIG的全称是Java Architectures Special Interest Group，是在高校中推广和探讨基于Java的开源技术的一个组织。CAS的优点很多，例如设计理念先进、体系结构合理、配置简单、客户端支持广泛、技术成熟等等。这也是我们这次SSO改造的参照产品。

以CAS为例，使用Cookie实现单点登录的原理图如图1所示。

• 首先，单点登录分为“服务端”和“客户端”。服务端就是单点登录服务器，而客户端通常是“函数库”或者“插件”。需要使用单点登录的应用程序，需要把客户端插件安装到自己的系统中，或者将客户端函数库包括在代码中。单点登录的客户端通常替换了原来应用程序的认证部分的代码。
• 某个应用程序首先要发起第1次认证。大部分情况下，应用程序中嵌入的客户端会把应用程序原来的登录画面屏蔽掉，而直接转到单点登录服务器的登录页面。

 

• 用户在单点登录服务器的登录页面中，输入用户名和密码。
• 然后单点登录服务器会对用户名和密码进行认证。认证本身并不是单点登录服务器的功能，因此，通常会引入某种认证机制。认证机制可以有很多种，例如自己写一个认证程序，或者使用一些标准的认证方法，例如LDAP或者数据库等等。在大多数情况下，会使用LDAP进行认证。这是因为LDAP在处理用户登录方面，有很多独特的优势，这在本文的后面还会比较详细地进行介绍。
• 认证通过之后，单点登录服务器会和应用程序进行一个比较复杂的交互，这通常是某种授权机制。CAS使用的是所谓的Ticket。具体这点后面还会介绍。
• 授权完成后，CAS把页面重定向，回到Web应用。Web应用此时就完成了成功的登录（当然这也是单点登录的客户端，根据返回的Ticket信息进行判断成功的）。
• 然后单点登录服务器会在客户端创建一个Cookie。注意，是在用户的客户端，而不是服务端创建一个Cookie。这个Cookie是一个加密的Cookie，其中保存了用户登录的信息。
• 如果用户此时希望进入其他Web应用程序，则安装在这些应用程序中的单点登录客户端，首先仍然会重定向到CAS服务器。不过此时CAS服务器不再要求用户输入用户名和密码，而是首先自动寻找Cookie，根据Cookie中保存的信息，进行登录。登录之后，CAS重定向回到用户的应用程序。

这样，就不再需要用户继续输入用户名和密码，从而实现了单点登录。