单点登录技术文档何伟民* 2010.61、单点登录概述单点登录的英文名称为Single Sign-On，简写为SSO，它是一个用户认证的过程，允许用户一次性进行认证之后，就访问系统中不同的应用；而不需要访问每个应用时，都重新输入密码。

IBM对SSO有一个形象的解释“单点登录、全网漫游”。

SSO将一个企业内部所有域中的用户登录和用户帐号管理集中到一起，SSO的好处显而易见：1. 减少用户在不同系统中登录耗费的时间，减少用户登录出错的可能性2. 实现安全的同时避免了处理和保存多套系统用户的认证信息3. 减少了系统管理员增加、删除用户和修改用户权限的时间4. 增加了安全性：系统管理员有了更好的方法管理用户，包括可以通过直接禁止和删除用户来取消该用户对所有系统资源的访问权限对于内部有多种应用系统的企业来说，单点登录的效果是十分明显的。

很多国际上的企业已经将单点登录作为系统设计的基本功能之一。

1.1单点登录产品商业SSO软件●专门的SSO商业软件⏹主要有：Netgrity的Siteminder，已经被CA收购。

Novell 公司的iChain。

RSA公司的ClearTrust等。

●门户产品供应商自己的SSO产品，⏹如：BEA的WLES，IBM 的Tivoli Access Manager，Sun 公司的identity Server，Oracle公司的OID等。

上述商业软件一般适用于客户对SSO的需求很高，并且企业内部采用Domino、SAP、Sieble等系统比较多的情况下。

单点登录产品通常需要在应用软件中增加代理模块，而商业SSO产品主要针对大型软件制作了代码模块。

因此，商业SSO软件除了价格问题外，另一个重要问题就是对客户自己的应用系统支持未必十分完善。

开源SSO软件●Opensso⏹https:///⏹OpenSSO基于Sun Java System Access Manager，是Sun公司支持的一个开源的SSO项目。

⏹OpenSSO体系结构设计合理，功能比较强大。

然而缺点是客户端支持不够广泛，似乎只是对基于J2EE的应用支持的比较好。

●josso⏹/⏹这是另一个Java写的单点登录产品，通常认为比OpenSSO更成熟一些。

⏹JOSSO支持的客户端包括Java，PHP和ASP。

●CAS⏹/products/cas/⏹这是耶鲁大学开发的单点登录产品，也是我们最后选定的单点登录产品。

⏹CAS的优点很多，例如设计理念先进、体系结构合理、配置简单、客户端支持广泛、技术成熟等等。

以后我们还要仔细介绍。

经过广泛分析和比较，最后我们选定CAS作为我们的单点登录产品。

我们确信这是目前能够找到的最好的开源单点登录产品。

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

WebLogic通过Session共享认证信息。

Session是一种服务器端机制，当客户端访问服务器时，服务器为客户端创建一个惟一的SessionID，以使在整个交互过程中始终保持状态，而交互的信息则可由应用自行指定，因此用Session方式实现SSO，不能在多个浏览器之间实现单点登录，但却可以跨域。

WebSphere通过Cookie记录认证信息。

Cookie是一种客户端机制，它存储的内容主要包括: 名字、值、过期时间、路径和域，路径与域合在一起就构成了Cookie的作用范围，因此用Cookie方式可实现SSO，但域名必须相同。

目前大部分SSO产品采用的是Cookie机制，CAS也是如此。

注意，这种机制要求实现单点登录的应用，其域名必须是相同的。

例如：,就可以经过配置后实现SSO。

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

●首先，单点登录分为“服务端”和“客户端”。

服务端就是单点登录服务器，而客户端通常是“函数库”或者“插件”。

需要使用单点登录的应用程序，需要把客户端插件安装到自己的系统中，或者将客户端函数库包括在代码中。

单点登录的客户端通常替换了原来应用程序的认证部分的代码。

●某个应用程序首先要发起第1次认证。

大部分情况下，应用程序中嵌入的客户端会把应用程序原来的登录画面屏蔽掉，而直接转到单点登录服务器的登录页面。

图 1 使用Cookie实现单点登录的原理图●用户在单点登录服务器的登录页面中，输入用户名和密码。

●然后单点登录服务器会对用户名和密码进行认证。

认证本身并不是单点登录服务器的功能，因此，通常会引入某种认证机制。

认证机制可以有很多种，例如自己写一个认证程序，或者使用一些标准的认证方法，例如LDAP或者数据库等等。

在大多数情况下，会使用LDAP进行认证。

这是因为LDAP在处理用户登录方面，有很多独特的优势，这在本文的后面还会比较详细地进行介绍。

●认证通过之后，单点登录服务器会和应用程序进行一个比较复杂的交互，这通常是某种授权机制。

CAS使用的是所谓的Ticket。

具体这点后面还会介绍。

●授权完成后，CAS把页面重定向，回到Web应用。

Web应用此时就完成了成功的登录（当然这也是单点登录的客户端，根据返回的Ticket信息进行判断成功的）。

●然后单点登录服务器会在客户端创建一个Cookie。

注意，是在用户的客户端，而不是服务端创建一个Cookie。

这个Cookie是一个加密的Cookie，其中保存了用户登录的信息。

●如果用户此时希望进入其他Web应用程序，则安装在这些应用程序中的单点登录客户端，首先仍然会重定向到CAS服务器。

不过此时CAS服务器不再要求用户输入用户名和密码，而是首先自动寻找Cookie，根据Cookie中保存的信息，进行登录。

登录之后，CAS重定向回到用户的应用程序。

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

注意，这种单点登录体系中，并没有通过http进行密码的传递（但是有用户名的传递），因此是十分安全的。

1.3单点登录、统一用户和单一用户管理很多人谈论单点登录时，常常和统一用户，以及单一用户管理混淆了，要么误认为单点登录自然实现了单一用户管理；要么误认为统一用户或者单一用户管理就是单点登录。

实际上，这三个概念是有明确的区别的。

统一用户就是指不同的系统，使用同一套用户处理的机制。

●用户ID全局惟一，用户登录名，密码全局唯一，并且统一存储在单一系统中。

●用户的一些属性，如姓名、电话、地址、邮件等，统一存储在单一系统中。

尽管各应用系统还可以自行增加一些属性，但是基本的属性应该统一存储和管理。

●应用系统不应该直接对用户信息的进行增加、修改和删除，但是可以进行查询。

对用户信息的增加、修改和删除，应该由专门的系统进行统一的管理。

目前比较标准的做法，是使用LDAP服务器，对用户信息进行统一管理。

很显然，统一用户是单点登录的基础，但是统一用户并不意味着实现了单点登录。

例如，如果我们在LDAP服务器中实现了用户的统一管理。

然后我们可以设置应用程序A和B都使用LDAP进行用户认证。

虽然此时A和B用以认证的用户，其用户名和密码都是一样的（都是从LDAP服务器中读出的），但是对应用A进行了登录之后，应用B还需要再次输入用户名和密码。

因此，统一用户并不意味着单点登录。

在图1中可以很清楚地看到，用于统一用户管理的LDAP服务器，只是单点登录系统中的一个部分，主要用于认证。

单一用户管理则指所有的用户管理工作都在唯一的地方进行处理，而每个应用程序不再保留自己的用户管理功能。

单一用户管理和统一用户管理的最大区别在于，统一用户管理之后，每个应用程序仍然保留自己的用户管理功能，用于额外的属性设置；而单一用户管理时，每个应用程序不再保留自己的用户管理功能。

我们举例来进行说明，最好的例子是“组”。

大家都知道，“组”通常包含若干个用户，用以方便地进行一些设置，例如权限设置等等。

在LDAP服务器上可以设置组，但是如果某个应用程序希望使用自己设定的组怎么办？只能让该应用程序保留设定组的功能。

那么又带来下面的问题。

如果应用程序中的组GroupA中，例如包含了用户User1和User2。

而在LDAP服务器进行统一用户管理时，把用户User1删除了，增加了User3。

此时GroupA中包含了一个无效的用户，并且缺少了一个有效的用户。

此时怎么办呢？也没有什么好的办法，只能进行用户的同步。

在LDAP中进行用户操作之后，有某种同步的机制，在应用程序中进行相应的修改。

再举一个例子，Zope中的用户，是具有不同的权限的。

而LDAP服务器中的用户，则通常没有权限这个属性。

那么，如果Zope使用LDAP作为自己的用户源，如何设定用户的属性呢？目前的解决方法是，在Zope中复制一个LDAP中的用户，然后手工设置用户的权限。

此时，由于用户被复制了，因此又带来了同步的问题。

因此，即使实现了统一用户管理，仍然可能需要在应用程序之间，设置大量的用户管理的同步操作（尽管比没有统一用户管理之前简单多了）。

这样，实际上没有达到所谓的“单一用户管理”，即在统一的地方进行全部的用户管理操作。

单一用户管理和应用程序的具体处理机制关系很大，因此目前还没有统一的方法进行处理。

这需要在设计应用程序，以及设计LDAP服务器时，进行仔细的设计，并有大量的代码改造工作。

2、C AS原理及相关软件2.1CAS原理简介CAS被设计为一个独立的Web应用，目前是通过若干个Java servlets来实现的。

CAS 必须运行在支持SSL的web服务器至上。

应用程序可以通过三个URL路径来使用CAS，分别是登录URL（login URL），校验URL（validation URL）和登出URL（logout URL）。

CAS的工作原理如图4所示。

图 2 CAS的工作原理●应用程序一开始，通常跳过原来的登陆界面，而直接转向CAS自带的登录界面。

当然也可以在应用程序的主界面上增加一个登录之类的按钮，来完成跳转工作。

⏹如果用户喜欢的话，也可以手工直接进入CAS的登录界面，先进行登录，在启动其他的应用程序。

不过这种模式主要用于测试环境。

●CAS的登录界面处理所谓的“主体认证”。

它要求用户输入用户名和密码，就像普通的登录界面一样，如图5所示。

图 3 CAS的登录界面●主体认证时，CAS获取用户名和密码，然后通过某种认证机制进行认证。

通常认证机制是LDAP。

●为了进行以后的单点登录，CAS向浏览器送回一个所谓的“内存cookie”。

这种cookie并不是真的保存在内存中，而只是浏览器一关闭，cookie就自动过期。

这个cookie称为“ticket-granting cookie”，用来表明用户已经成功地登录。

●认证成功后，CAS服务器创建一个很长的、随机生成的字符串，称为“Ticket”。

随后，CAS将这个ticket和成功登录的用户，以及服务联系在一起。