单点登录技术详解

原文地址：单点登录技术详解 作者：阿木

单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

　　企业应用集成（EAI）。企业应用集成可以在不同层面上进行：例如在数据存储层面上的“数据大集中”，在传输层面上的“通用数据交换平台”，在应用层面上的“业务流程整合”，和用户界面上的“通用企业门户”等等。事实上，还用一个层面上的集成变得越来越重要，那就是“身份认证”的整合，也就是“单点登录”。

　　单点登录的技术实现机制：当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭据－－ticket；用户再访问别的应用的时候，就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行效验，检查ticket的合法性。如果通过效验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。

　　可以看出，要实现SSO，需要以下主要的功能：

　　所有应用系统共享一个身份认证系统；

　　所有应用系统能够识别和提取ticket信息；

　　应用系统能够识别已经登录过的用户，能自动判断当前用户是否登录过，从而完成单点登录的功能。

　　其中统一的身份认证系统最重要，认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。整个系统可以存在两个以上的认证服务器，这些服务器甚至可以是不同的产品。认证服务器之间要通过标准的通讯协议，互相交换认证信息，就能完成更高级别的单点登录。

 

网站用户单点登录系统解决方案

1 背景 　　在网站建设的过程中，多个应用系统一般是在不同的时期开发完成的。各应用系统由于功能侧重、设计方法和开发技术有所不同，也就形成了各自独立的用户库和用户认证体系。随着网站的发展，会出现这样的用户群体：以其中的一个用户为例，他（她）使用网站的多个应用系统，但在每个应用系统中有独立的账号，没有一个整体上的网站用户账号的概念，进入每一个应用系统前都需要以该应用系统的账号来登录。这带给用户不方便的使用感受，用户会想：既然我使用的是同一个网站上的应用，为什么不能在一次在网站上登录之后不必再经过应用系统认证直接进入应用系统呢？用户的要求我们称之为 "单点登录"。 图 1.1 网站用户要求单点登录   2 分析 　　在多个拥有各自独立的用户体系的应用系统间实现单点登录，我们要考虑以下的问题： 单点登录系统的实现在各应用系统都采用B/S模式这一前提下进行。 需要在各应用系统间统一用户认证标志，用户登录后可以得到用户令牌，各应用系统认可统一的用户令牌。 用户令牌应当是安全加密的，并且要限定时效期。 由于每个应用系统都有自己的用户库，一个用户可能在不同的应用系统中使用不同的账号，因此每个要使用多个应用系统的用户要设置一个统一的用户账号并以此账号进行单点登录，该账号与该用户在各应用系统中的一个账号形成映射关系。 各应用系统可能属于不同的域，因此要实现跨域的单点登录。 已经上线运行的应用系统需要进行改造来支持单点登录，正在开发的应用系统则可以在开发阶段增加对单点登录的支持，但应用系统之间应该是松耦合。 由于各应用系统往往都已经处于稳定运行期，单点登录系统的实现应该对各应用系统的登录认证体系冲击最小，各应用系统原有的登录流程依然可用。 一些应用服务器平台虽然提供对单点登录的支持，但要求应用系统用户认证的设计符合其规范，这对已经处于运行期的应用系统来说难以实现。 3 设计 　　以下是系统的整体设计结构： 图 3.1 系统结构图 3.1 单点登录管理应用 　　我们首先设计单点登录管理应用： 图 3.2 单点登录管理应用 　　用户在其中注册一个单点登录账号，然后针对每个应用系统绑定一个该应用系统中原有的账号，并维护这些注册和绑定信息。绑定的过程需要单点登录管理应用服务器到应用系统服务器上验证用户提供的该应用系统中原有账号和密码，应用服务器均以相同的Web Service接口提供该功能支持。 3.2 用户单点登录流程 　　 之后以用户单点登录管理应用和令牌传输识别的标准来实现用户单点登录流程。 1、用户访问应用系统。 图 3.3 用户单点登录流程 - 步骤一 2、应用系统如果检查到用户没有在自己的服务器登录，则将用户请求重定向到单点登录服务器上。（使用重定向就可以处理各服务器跨域的情况） 图 3.4 用户单点登录流程 - 步骤二 3、单点登录服务器检查到用户已经单点登录（如果用户没有单点登录则要求用户登录，登录标志存储为客户端浏览器的Cookie），找到该用户在相应应用系统上绑定的账号。 图 3.5 用户单点登录流程 - 步骤三 4、单点登录服务器根据第三步的结果生成用户令牌，重定向回应用系统。 图 3.6 用户单点登录流程 - 步骤四 5、应用系统接收统一格式的用户令牌，取得用户在本系统上的登录账号，将用户在本系统上状态置为登录，返回用户请求访问的页面。 图 3.7 用户单点登录流程 - 步骤五   　　如果用户在访问应用系统之前已经在单点登录服务器上登录过，第二步到第四布对用户来说就是透明的，用户感觉只是向应用系统发出了访问请求，然后得到了页面反馈。 4 实现 (略) 5 总结 　　本方案设计的用户单点登录系统做到了： 真正了实现单点登录、全网访问，方便用户的使用过程。 各系统之间耦合度低，应用系统的改造不破坏其固有流程和结构，整个系统的实施过程安全平滑。 统一了单点登录服务器到应用服务器的用户认证信息访问标准，统一了令牌安全加密的传输和识别标准，为将来更多应用系统提供了统一的单点登录框架。 整合了过去分散在各应用系统中虽然有内在关联却难以判别的用户信息资源，为更进一步的用户个性化服务打下了基础。

 实现部分:

１．利用Cookie实现一站式登陆

　　共享Cookie的所有应用必须是在同一域名下的二级域，否则Cookie不能实现共享。
　　必须将Cookie的路径设置为根，否则在不同路径下的应用不能贡献Cookie。
　　例子：Cookie cookie = new Cookie(“xxxlogin”，“123456”);
　　　　　cookie.setDomain(".xxx.com");//域名必须以点开头
　　　　　cookie.setPath("/");

２．CAS(Central Authentication Service) 是 Yale 大学发起的一个开源项目。可以方便的实现ava 、 .Net 、 ISAPI 、 Php 、 Perl 、 Ruby等语言开发的各种WEB程序统一进行单点登陆。从实现的架构和安全等方面CAS完全可以胜任SSO的实现，但是CAS在实现的过程中需要按照自己的设计对服务器端的程序进行改造，同时需要所有的服务器按照CAS的实现方式进行相应的改造来实现统一的登陆程序

　　CAS Server
　　CAS Server 负责完成对用户的认证工作， CAS Server 需要独立部署，有不止一种 CAS Server 的实现， Yale CAS Server 和 ESUP CAS Server 都　　是很不错的选择。
　　CAS Server 会处理用户名 / 密码等凭证 (Credentials) ，它可能会到数据库检索一条用户帐号信息，也可能在 XML 文件中检索用户密码，对这种方　　　　式， CAS 均提供一种灵活但同一的接口 / 实现分离的方式， CAS 究竟是用何种认证方式，跟 CAS 协议是分离的，也就是，这个认证的实现细节可以自己定　　制和扩展。

　　CAS Client
　　CAS Client 负责部署在客户端（注意，我是指 Web 应用），原则上， CAS Client 的部署意味着，当有对本地 Web 应用的受保护资源的访问请求，并且　　需要对请求方进行身份认证， Web 应用不再接受任何的用户名密码等类似的 Credentials ，而是重定向到 CAS Server 进行认证。
　　目前， CAS Client 支持（某些在完善中）非常多的客户端，包括 Java 、 .Net 、 ISAPI 、 Php 、 Perl 、 uPortal 、 Acegi 、 Ruby 、 　　　　　VBScript 等客户端，几乎可以这样说， CAS 协议能够适合任何语言编写的客户端应用。