信息集成中的单点登录技术

 SSO（Single Sign-On）直译为一次登录，用户只使用一个用户名和口令，就可以访问所有的资源，这对系统管理和维护来说是非常重要的。单点登录有效地解决了用户使用网络时的多帐号、多密码、多次登录问题，方便了用户。

SSO理论基础

SSO并不是J2EE（或.Net）中的标准实现，而是各家中间件提供商在提供J2EE（或.Net）应用服务器时提供的一种认证信息共享的机制，所以各家厂商提供的实现方式不一样, 在这些系统中，其实现方法方向分为两种: 一种是建立在PKI，Kerbose和用户名/口令存储的基础上,一种是建立在cookie或session的基础上。IBM的WebSphere是通过cookies记录认证信息，BEA的WebLogic通过session共享技术实现认证信息的共享，国内深圳金蝶的apusic采用的和BEA的技术基本一致。在这两种方式中，各有不足，前者需要安装专门的客户端，因而面向的用户对象是有限的，而后者授权方式只能方便地支持本产品系列的应用，而对第三方的认证和权限系统不能很方便的集成。

SSO的前提条件

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

所有服务器必须共享用户注册表（用户数据库），用户注册表可以是LDAP数据库，也可以采用用户自己实现的用户注册表。要注意的是在某些情况下是不能使用自己实现的用户注册表的，例如，Domino不支持用户自己实现的用户注册表，所以WebSphere和Domino之间实现SSO时只能采用LDAP数据库作为公有的用户注册表。

统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（token），返还给用户。另外，认证系统还应该对token进行效验，判断其有效性。

2、所有应用系统能够识别和提取token信息

要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对token进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。

3、单一的用户信息数据库并不是必须的

有许多系统不能将所有的用户信息都集中存储，应该允许用户信息放置在不同的存储中。事实上，只要统一认证系统，统一token的产生和效验，无论用户信息存储在什么地方，都能实现单点登录。

4、统一的认证系统并不是说只有单个的认证服务器

认证服务器之间要通过标准的通讯协议，互相交换认证信息，就能完成更高级别的单点登录。如：当用户在访问应用系统1时，由第一个认证服务器进行认证后，得到由此服务器产生的token。当他访问应用系统2的时候，认证服务器2能够识别此token是由第一个服务器产生的，通过认证服务器之间标准的通讯协议（例如SAML）来交换认证信息，仍然能够完成SSO的功能。

5、对应用系统的修改不可避免

并不是任何系统都能够使用SSO，只有那些符合SSO规范，使用SSO API的应用系统才具有SSO的功能。简单地说就是要修改已有的应用系统（在本项目中，已有的业务系统要实现单点登录，如果步具备相应的条件，则必须进行修改），屏蔽已有的应用系统的用户认证模块，使用系统提供的SSO API来验证用户，以及对用户的操作进行授权。

实现单点登录的两种方式

SSO都要有一个单一的登录点，由此登录点将创建的会话（认证标志）token传递给应用系统。SSO需要建立一个统一的认证、权限信息库。根据认证、授权实现的位置可以分为两种实现方式：

1、Agent的方式

即在后端为每个Web应用系统（或者其他系统）都安装一个Agent，由Agent来接管该系统的身份验证和访问控制，目录服务器中会存放自己的用户信息，以及这些用户与其他系统的用户对应信息。这些Agent能够通过配置，轻松的接管了后面的系统的身份验证和访问控制。

对于不同的系统，Agent不同，这些Agent能够通过配置，轻松的接管后面系统的身份验证和访问控制。可以通过一个统一的LDAP，存放企业内部的用户信息，然后通过策略服务器，控制后端所有系统的URL访问权限，这样也实现了单点登录。

使用这种方式，其安全性较高，用户信息都保存在各系统中，但是这种方式需要在各个系统中都安装Agent，降低了系统的灵活性。

2、Proxy的方式

即具有一个Proxy Server，由它来接管对于后端系统的访问，提交请求和读取数据，然后再返回给调用者。同时调用者可以存放用户信息以及用户的对应关系。Proxy Server会通过存储的用户对应关系和用户名和密码，自动完成后端系统的登录，然后就象一个浏览器一样，提取数据，返回数据给后端系统。后台系统不用做任何修改，身份认证和访问控制仍然由各个系统自己管理。

该方法的优点是：后端系统不用做任何改动。即便是没有Portal，其他系统还可以照常使用。缺点是：需要在策略服务器中存储用户名称和密码，密码会多处存放，同步困难；用户可以绕开Portal，直接访问后端系统。Proxy Server可能是单点故障。缺点解决：目前有密码同步产品；Proxy Server也大多支持集群。

由以上两种方式可以看出，哪种方式的编程量都不是很大，大多可以通过配置来实现，而且功能也很强大，可以根据系统实际情况进行选择。

基于Agent方式的单点登录实现流程

在每个Web应用系统都安装一个Agent，由Agent来接管该系统的身份验证和访问控制的方式实现,如下图所示.

图 基于Agent方式的单点登录实现过程

1、用户访问应用系统。由登录点将SSO token（针对不同的C/S，B/S应用可能还需要传递用户名，口令）传递给应用系统，应用系统利用SSO token来进行用户已认证的验证。

2、当用户试图通过浏览器存取受保护的应用资源时，系统提供安装在不同应用上的SSO Agent来截取用户对资源的请求，并检查请求是否存在会话标识符，即token。如果token不存在，即用户没有在自己的服务器登录，请求就被重定向，传递给单点登录服务器（使用重定向就可以处理各服务器跨域的情况）。在单点登录服务器上会话服务负责创建会话token，然后认证服务将提供登陆页面以验证用户。

在用户身份验证之前，会话服务创建了会话token。token为随机产生的会话标识符，该标识符代表了一个确定用户的特定会话。创建会话token后，认证服务把token插入cookie中，在用户的浏览器中设定cookie。在token被设定的同时，该用户将会看到一个登陆页面。

Cookie是由Web服务器创建的信息包，并传递给浏览器。Cookie 保存类似用户习惯等Web服务器产生的信息。它本身并不表明用户通过了认证。Cookie是特定于某个域的。在身份服务器的实现中，cookie由会话服务产生，并由认证服务设定。而且，身份服务器的cookie是会话cookie，存储在内存中。会话token由会话服务创建并插入Cookie。会话token利用安全随机数发生器产生，并包含系统服务器特有的会话信息。在存取受保护的资源之前，用户由认证服务验证，并创建SSO token。

3、单点登录服务器检查到用户已经单点登录（如果用户没有单点登录则要求用户登录，登录标志存储为客户端浏览器的Cookie），找到该用户在相应应用系统上绑定的账号。这些认证信息就被发给认证提供者（authentication provider）（LDAP服务器，RADIUS服务器等）进行验证。

4、一旦认证提供者成功验证了认证信息，用户就被认为是通过了认证。身份服务器会从用户的token中取出会话信息并将会话状态设为有效。单点登录服务器根据生成的用户token，重定向回应用系统。此后，用户就可以访问这些受保护的资源。

5、应用系统接收统一格式的用户token，取得用户在本系统上的登录账号，将用户在本系统上状态置为登录，返回用户请求访问的页面。

如果用户在访问应用系统之前已经在单点登录服务器上登录过，第二步到第四布对用户来说就是透明的，用户感觉只是向应用系统发出了访问请求，然后得到了页面反馈。

基于Proxy方式的单点登录实现流程

基于proxy的实现方案如novel iChain的实现。这种方案需要通过DNS将多个系统的域名配置在一个承担SSO的Proxy上。当用户输入系统地址打开页面时，会首先链接到这个Proxy，再由Proxy转发到实际系统。原有系统因为用户没有登录，那么会返回登录页面，这时候iChain会截获这个登录页面，用自己的登录页面代替。用户在iChain提供的页面中输入用户名和密码，随后iChain根据LDAP（Novel的LDAP可以说是这行的老大了）中的信息查询出原有系统的用户名和密码，通过一次Http Post将用户账号发送给原有系统。 

如果用户打开新系统页面，那么基本不骤不变，只是iChain返回自己登录页面时，因为在同一个域中，可以发现该用户已经登录过，然后就直接Http Post到新系统而不出现登录页面。

其实SSO只是最简单的一个步骤，如何做好多系统之间的账号同步和授权才是大难题。