37856人阅读
单点登录（Single Sign On , 简称 SSO ）是目前比较流行的服务于企业业务整合的解决方案之一， SSO 使得在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。CAS(Central Authentication Service)是一款不错的针对 Web 应用的单点登录框架，本文介绍了 CAS 的原理、协议、在 Tomcat 中的配置和使用，对于采用 CAS 实现轻量级单点登录解决方案的入门读者具有一定指导作用。
CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。CAS 具有以下特点：
开源的企业级单点登录解决方案。
CAS Server 为需要独立部署的 Web 应用。
CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用)，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
从结构上看，CAS 包含两个部分： CAS Server 和 CAS Client。CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。图1 是 CAS 最基本的协议过程：
CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求，CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。用户在第 3 步中输入认证信息，如果登录成功，CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket，并缓存以待将来验证，之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie（TGC），CAS Client 在拿到 Service 和新产生的 Ticket 过后，在第 5，6 步中与 CAS Server 进行身份合适，以确保 Service Ticket 的合法性。
在该协议中，所有与 CAS 的交互均采用 SSL 协议，确保，ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程，但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。
另外，CAS 协议中还提供了 Proxy （代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考 CAS 官方网站上的相关文档。
本文中的例子以 tomcat5.5 为例进行讲解，下载地址：
到 CAS 官方网站下载 CAS Server 和 Client，地址分别为：
CAS Server 是一套基于 Java 实现的服务，该服务以一个 Java Web Application 单独部署在与 servlet2.3 兼容的 Web 服务器上，另外，由于 Client 与 CAS Server 之间的交互采用 Https 协议，因此部署 CAS Server 的服务器还需要支持 SSL 协议。当 SSL 配置成功过后，像普通 Web 应用一样将 CAS Server 部署在服务器上就能正常运行了，不过，在真正使用之前，还需要扩展验证用户的接口。
在 Tomcat 上部署一个完整的 CAS Server 主要按照以下几个步骤：
如果希望 Tomcat 支持 Https，主要的工作是配置 SSL 协议，其配置过程和配置方法可以参考 Tomcat 的相关文档。不过在生成证书的过程中，会有需要用到主机名的地方，CAS 建议不要使用 IP 地址，而要使用机器名或域名。
CAS Server 是一个 Web 应用包，将前面下载的 cas-server-3.1.1-release.zip 解开，把其中的 cas-server-webapp-3.1.1.war 拷贝到 tomcat的 webapps 目录，并更名为 cas.war。由于前面已配置好 tomcat 的 https 协议，可以重新启动 tomcat，然后访问：https://localhost:8443/cas ，如果能出现正常的 CAS 登录页面，则说明 CAS Server 已经部署成功。
虽然 CAS Server 已经部署成功，但这只是一个缺省的实现，在实际使用的时候，还需要根据实际概况做扩展和定制，最主要的是扩展认证 (Authentication) 接口和 CAS Server 的界面。
CAS Server 负责完成对用户的认证工作，它会处理登录时的用户凭证 (Credentials) 信息，用户名/密码对是最常见的凭证信息。CAS Server 可能需要到数据库检索一条用户帐号信息，也可能在 XML 文件中检索用户名/密码，还可能通过 LDAP Server 获取等，在这种情况下，CAS 提供了一种灵活但统一的接口和实现分离的方式，实际使用中 CAS 采用哪种方式认证是与 CAS 的基本协议分离开的，用户可以根据认证的接口去定制和扩展。
扩展 AuthenticationHandler
CAS 提供扩展认证的核心是 AuthenticationHandler 接口，该接口定义如清单 1 下：
public interface AuthenticationHandler {
* Method to determine if the credentials supplied are valid.
* @param credentials The credentials to validate.
* @return true if valid, return false otherwise.
* @throws AuthenticationException An AuthenticationException can contain
* details about why a particular authentication request failed.
boolean authenticate(Credentials credentials) throws AuthenticationE/**
* Method to check if the handler knows how to handle the credentials
* provided. It may be a simple check of the Credentials class or something
* more complicated such as scanning the information contained in the
* Credentials object.
* @param credentials The credentials to check.
* @return true if the handler supports the Credentials, false othewrise.
boolean supports(Credentials credentials);}
该接口定义了 2 个需要实现的方法，supports ()方法用于检查所给的包含认证信息的Credentials 是否受当前 AuthenticationHandler 支持；而 authenticate() 方法则担当验证认证信息的任务，这也是需要扩展的主要方法，根据情况与存储合法认证信息的介质进行交互，返回 boolean 类型的值，true 表示验证通过，false 表示验证失败。
CAS3中还提供了对AuthenticationHandler 接口的一些抽象实现，比如，可能需要在执行authenticate() 方法前后执行某些其他操作，那么可以让自己的认证类扩展自清单 2 中的抽象类：
public abstract class AbstractPreAndPostProcessingAuthenticationHandler
implements AuthenticateHandler{
protected Log log = LogFactory.getLog(this.getClass());
protected boolean preAuthenticate(final Credentials credentials) {
protected boolean postAuthenticate(final Credentials credentials,
final boolean authenticated) {
public final boolean authenticate(final Credentials credentials)
throws AuthenticationException {
if (!preAuthenticate(credentials)) {
final boolean authenticated = doAuthentication(credentials);
return postAuthenticate(credentials, authenticated);
protected abstract boolean doAuthentication(final Credentials credentials) throws AuthenticationE}
AbstractPreAndPostProcessingAuthenticationHandler 类新定义了 preAuthenticate() 方法和 postAuthenticate() 方法，而实际的认证工作交由 doAuthentication() 方法来执行。因此，如果需要在认证前后执行一些额外的操作，可以分别扩展 preAuthenticate()和 ppstAuthenticate() 方法，而 doAuthentication() 取代 authenticate() 成为了子类必须要实现的方法。
由于实际运用中，最常用的是用户名和密码方式的认证，CAS3 提供了针对该方式的实现，如清单 3 所示：
public abstract class AbstractUsernamePasswordAuthenticationHandler extends
AbstractPreAndPostProcessingAuthenticationHandler{... protected final boolean doAuthentication(final Credentials credentials) throws AuthenticationException { return authenticateUsernamePasswordInternal((UsernamePasswordCredentials) credentials); } protected abstract boolean authenticateUsernamePasswordInternal(
final UsernamePasswordCredentials credentials) throws AuthenticationE
protected final PasswordEncoder getPasswordEncoder() { return this.passwordE }public final void setPasswordEncoder(final PasswordEncoder passwordEncoder) { this.passwordEncoder = passwordE
基于用户名密码的认证方式可直接扩展自 AbstractUsernamePasswordAuthenticationHandler，验证用户名密码的具体操作通过实现 authenticateUsernamePasswordInternal() 方法达到，另外，通常情况下密码会是加密过的，setPasswordEncoder() 方法就是用于指定适当的加密器。
从以上清单中可以看到，doAuthentication() 方法的参数是 Credentials 类型，这是包含用户认证信息的一个接口，对于用户名密码类型的认证信息，可以直接使用 UsernamePasswordCredentials，如果需要扩展其他类型的认证信息，需要实现Credentials接口，并且实现相应的 CredentialsToPrincipalResolver 接口，其具体方法可以借鉴 UsernamePasswordCredentials 和 UsernamePasswordCredentialsToPrincipalResolver。
JDBC 认证方法
用户的认证信息通常保存在数据库中，因此本文就选用这种情况来介绍。将前面下载的 cas-server-3.1.1-release.zip 包解开后，在 modules 目录下可以找到包 cas-server-support-jdbc-3.1.1.jar，其提供了通过 JDBC 连接数据库进行验证的缺省实现，基于该包的支持，我们只需要做一些配置工作即可实现 JDBC 认证。
JDBC 认证方法支持多种数据库，DB2, Oracle, MySql, Microsoft SQL Server 等均可，这里以 DB2 作为例子介绍。并且假设DB2数据库名： CASTest，数据库登录用户名： db2user，数据库登录密码： db2password，用户信息表为： userTable，该表包含用户名和密码的两个数据项分别为 userName 和 password。
1. 配置 DataStore
打开文件 %CATALINA_HOME%/webapps/cas/WEB-INF/deployerConfigContext.xml，添加一个新的 bean 标签，对于 DB2，内容如清单 4 所示：
&bean id="casDataSource" class="mons.dbcp.BasicDataSource"&
&property name="driverClassName"&
&value&com.ibm.db2.jcc.DB2Driver&/value&
&/property&
&property name="url"&
&value&jdbc:db2://9.125.65.134:50000/CASTest&/value&
&/property&
&property name="username"&
&value&db2user&/value&
&/property&
&property name="password"&
&value&db2password&/value&
&/property&&/bean&
其中 id 属性为该 DataStore 的标识，在后面配置 AuthenticationHandler 会被引用，另外，需要提供 DataStore 所必需的数据库驱动程序、连接地址、数据库登录用户名以及登录密码。
2. 配置 AuthenticationHandler
在 cas-server-support-jdbc-3.1.1.jar 包中，提供了 3 个基于 JDBC 的 AuthenticationHandler，分别为 BindModeSearchDatabaseAuthenticationHandler, QueryDatabaseAuthenticationHandler, SearchModeSearchDatabaseAuthenticationHandler。其中 BindModeSearchDatabaseAuthenticationHandler 是用所给的用户名和密码去建立数据库连接，根据连接建立是否成功来判断验证成功与否；QueryDatabaseAuthenticationHandler 通过配置一个 SQL 语句查出密码，与所给密码匹配；SearchModeSearchDatabaseAuthenticationHandler 通过配置存放用户验证信息的表、用户名字段和密码字段，构造查询语句来验证。
使用哪个 AuthenticationHandler，需要在 deployerConfigContext.xml 中设置，默认情况下，CAS 使用一个简单的 username=password 的 AuthenticationHandler，在文件中可以找到如下一行：&bean class="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler" /&，我们可以将其注释掉，换成我们希望的一个 AuthenticationHandler，比如，使用QueryDatabaseAuthenticationHandler 或 SearchModeSearchDatabaseAuthenticationHandler 可以分别选取清单 5 或清单 6 的配置。
&bean class="org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler"& &property name="dataSource" ref=" casDataSource " /& &property name="sql"
value="select password from userTable where lower(userName) = lower(?)" /&&/bean&
&bean id="SearchModeSearchDatabaseAuthenticationHandler"
class="org.jasig.cas.adaptors.jdbc.SearchModeSearchDatabaseAuthenticationHandler"
abstract="false" singleton="true" lazy-init="default"
autowire="default" dependency-check="default"&
name="tableUsers"&
&value&userTable&/value&
&/property&
&property name="fieldUser"&
&value&userName&/value&
&/property&
&property name="fieldPassword"&
&value&password&/value&
&/property&
&property name="dataSource" ref=" casDataSource " /&&/bean&
另外，由于存放在数据库中的密码通常是加密过的，所以 AuthenticationHandler 在匹配时需要知道使用的加密方法，在 deployerConfigContext.xml 文件中我们可以为具体的 AuthenticationHandler 类配置一个 property，指定加密器类，比如对于 QueryDatabaseAuthenticationHandler，可以修改如清单7所示：
&bean class="org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler"&
&property name="dataSource" ref=" casDataSource " /&
&property name="sql"
value="select password from userTable where lower(userName) = lower(?)" /&
name="passwordEncoder"
ref="myPasswordEncoder"/&&/bean&
其中 myPasswordEncoder 是对清单 8 中设置的实际加密器类的引用：
&bean id="passwordEncoder"
class="org.jasig.cas.authentication.handler.MyPasswordEncoder"/&
这里 MyPasswordEncoder 是根据实际情况自己定义的加密器，实现 PasswordEncoder 接口及其 encode() 方法。
3. 部署依赖包
在以上配置完成以后，需要拷贝几个依赖的包到 cas 应用下，包括：
将 cas-server-support-jdbc-3.1.1.jar 拷贝到 %CATALINA_HOME%/webapps/cas/ WEB-INF/lib 目录。
数据库驱动，由于这里使用 DB2，将 %DB2_HOME%/java 目录下的 db2java.zip （更名为 db2java.jar）, db2jcc.jar, db2jcc_license_cu.jar 拷贝到 %CATALINA_HOME%/webapps/cas/WEB-INF/lib 目录。对于其他数据库，同样将相应数据库驱动程序拷贝到该目录。
DataStore 依赖于 commons-collections-3.2.jar, commons-dbcp-1.2.1.jar, commons-pool-1.3.jar，需要到 apache 网站的 Commons 项目下载以上 3 个包放进 %CATALINA_HOME%/webapps/cas/WEB-INF/lib 目录。
CAS 提供了 2 套默认的页面，分别为& default &和& simple &，分别在目录& cas/WEB-INF/view/jsp/default &和& cas/WEB-INF/view/jsp/simple &下。其中 default 是一个稍微复杂一些的页面，使用 CSS，而 simple 则是能让 CAS 正常工作的最简化的页面。
在部署 CAS 之前，我们可能需要定制一套新的 CAS Server 页面，添加一些个性化的内容。最简单的方法就是拷贝一份 default 或 simple 文件到& cas/WEB-INF/view/jsp &目录下，比如命名为 newUI，接下来是实现和修改必要的页面，有 4 个页面是必须的：
casConfirmView.jsp: 当用户选择了& warn &时会看到的确认界面
casGenericSuccess.jsp: 在用户成功通过认证而没有目的Service时会看到的界面
casLoginView.jsp: 当需要用户提供认证信息时会出现的界面
casLogoutView.jsp: 当用户结束 CAS 单点登录系统会话时出现的界面
CAS 的页面采用 Spring 框架编写，对于不熟悉 Spring 的使用者，在修改之前需要熟悉该框架。
页面定制完过后，还需要做一些配置从而让 CAS 找到新的页面，拷贝& cas/WEB-INF/classes/default_views.properties &，重命名为& cas/WEB-INF/classes/ newUI_views.properties &，并修改其中所有的值到相应新页面。最后是更新& cas/WEB-INF/cas-servlet.xml &文件中的 viewResolver，将其修改为如清单 9 中的内容。
&bean id="viewResolver"
class="org.springframework.web.servlet.view.ResourceBundleViewResolver" p:order="0"&
&property name="basenames"&
&value&${cas.viewResolver.basename}&/value&
&value& newUI_views&/value&
&/property&&/bean&
单点登录的目的是为了让多个相关联的应用使用相同的登录过程，本文在讲解过程中构造 2个简单的应用，分别以 casTest1 和 casTest2 来作为示例，它们均只有一个页面，显示欢迎信息和当前登录用户名。这 2 个应用使用同一套登录信息，并且只有登录过的用户才能访问，通过本文的配置，实现单点登录，即只需登录一次就可以访问这两个应用。
假设 CAS Server 单独部署在一台机器 A，而客户端应用部署在机器 B 上，由于客户端应用与 CAS Server 的通信采用 SSL，因此，需要在 A 与 B 的 JRE 之间建立信任关系。
首先与 A 机器一样，要生成 B 机器上的证书，配置 Tomcat 的 SSL 协议。其次，下载 的 InstallCert.java，运行& java InstallCert compA:8443 &命令，并且在接下来出现的询问中输入 1。这样，就将 A 添加到了 B 的 trust store 中。如果多个客户端应用分别部署在不同机器上，那么每个机器都需要与 CAS Server 所在机器建立信任关系。
准备好应用 casTest1 和 casTest2 过后，分别部署在 B 和 C 机器上，由于 casTest1 和casTest2，B 和 C 完全等同，我们以 casTest1 在 B 机器上的配置做介绍，假设 A 和 B 的域名分别为 domainA 和 domainB。
将 cas-client-java-2.1.1.zip 改名为 cas-client-java-2.1.1.jar 并拷贝到 casTest1/WEB-INF/lib目录下，修改 web.xml 文件，添加 CAS Filter，如清单 10 所示：
&filter-name&CAS Filter&/filter-name&
&filter-class&edu.yale.its.tp.cas.client.filter.CASFilter&/filter-class&
&init-param&
&param-name&edu.yale.its.tp.cas.client.filter.loginUrl&/param-name&
&param-value&https://domainA:8443/cas/login&/param-value&
&/init-param&
&init-param&
&param-name&edu.yale.its.tp.cas.client.filter.validateUrl&/param-name&
&param-value&https://domainA:8443/cas/serviceValidate&/param-value&
&/init-param&
&init-param&
&param-name&edu.yale.its.tp.cas.client.filter.serverName&/param-name&
&param-value&domainB:8080&/param-value&
&/init-param&
&filter-mapping&
&filter-name&CAS Filter&/filter-name&
&url-pattern&/protected-pattern/*&/url-pattern&
&/filter-mapping&
...&/web-app&
对于所有访问满足 casTest1/protected-pattern/ 路径的资源时，都要求到 CAS Server 登录，如果需要整个 casTest1 均受保护，可以将 url-pattern 指定为&/*&。
从清单 10 可以看到，我们可以为 CASFilter 指定一些参数，并且有些是必须的， 和 中分别是必需和可选的参数：
edu.yale.its.tp.cas.client.filter.loginUrl
指定 CAS 提供登录页面的 URL
edu.yale.its.tp.cas.client.filter.validateUrl
指定 CAS 提供 service ticket 或 proxy ticket 验证服务的 URL
edu.yale.its.tp.cas.client.filter.serverName
指定客户端的域名和端口，是指客户端应用所在机器而不是 CAS Server 所在机器，该参数或 serviceUrl 至少有一个必须指定
edu.yale.its.tp.cas.client.filter.serviceUrl
该参数指定过后将覆盖 serverName 参数，成为登录成功过后重定向的目的地址
edu.yale.its.tp.cas.client.filter.proxyCallbackUrl
用于当前应用需要作为其他服务的代理(proxy)时获取 Proxy Granting Ticket 的地址
edu.yale.its.tp.cas.client.filter.authorizedProxy
用于允许当前应用从代理处获取 proxy tickets，该参数接受以空格分隔开的多个 proxy URLs，但实际使用只需要一个成功即可。当指定该参数过后，需要修改 validateUrl 到 proxyValidate，而不再是 serviceValidate
edu.yale.its.tp.cas.client.filter.renew
如果指定为 true，那么受保护的资源每次被访问时均要求用户重新进行验证，而不管之前是否已经通过
edu.yale.its.tp.cas.client.filter.wrapRequest
如果指定为 true，那么 CASFilter 将重新包装 HttpRequest,并且使 getRemoteUser() 方法返回当前登录用户的用户名
edu.yale.its.tp.cas.client.filter.gateway
指定 gateway 属性
CAS 在登录成功过后，会给浏览器回传 Cookie，设置新的到的 Service Ticket。但客户端应用拥有各自的 Session，我们要怎么在各个应用中获取当前登录用户的用户名呢？CAS Client 的 Filter 已经做好了处理，在登录成功后，就可以直接从 Session 的属性中获取，如清单 11 所示：
// 以下两者都可以session.getAttribute(CASFilter.CAS_FILTER_USER);session.getAttribute("edu.yale.its.tp.cas.client.filter.user");
在 JSTL 中获取用户名的方法如清单 12 所示：
&c:out value="${sessionScope[CAS:'edu.yale.its.tp.cas.client.filter.user']}"/&
另外，CAS 提供了一个 CASFilterRequestWrapper 类，该类继承自HttpServletRequestWrapper，主要是重写了 getRemoteUser() 方法，只要在前面配置 CASFilter 的时候为其设置& edu.yale.its.tp.cas.client.filter.wrapRequest &参数为 true，就可以通过 getRemoteUser（） 方法来获取登录用户名，具体方法如清单 13 所示：
CASFilterRequestWrapper
reqWrapper=new CASFilterRequestWrapper(request);out.println("The logon user:" + reqWrapper.getRemoteUser());
在 casTest1 和 casTest2 中，都有一个简单 Servlet 作为欢迎页面 WelcomPage，且该页面必须登录过后才能访问，页面代码如清单 14 所示：
public class WelcomePage extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("&html&");
out.println("&head&");
out.println("&title&Welcome to casTest2 sample System!&/title&");
out.println("&/head&");
out.println("&body&");
out.println("&h1&Welcome to casTest1 sample System!&/h1&");
CASFilterRequestWrapper
reqWrapper=new CASFilterRequestWrapper(request);
out.println("&p&The logon user:" + reqWrapper.getRemoteUser() + "&/p&");
HttpSession session=request.getSession();
out.println("&p&The logon user:" +
session.getAttribute(CASFilter.CAS_FILTER_USER)
+ "&/p&");
out.println("&p&The logon user:" +
session.getAttribute("edu.yale.its.tp.cas.client.filter.user") + "&/p&");
out.println("&/body&");
out.println("&/html&");
在上面所有配置结束过后，分别在 A， B， C上启动 cas， casTest1 和 casTest2，按照下面步骤来访问 casTest1 和 casTest2：
打开浏览器，访问
，浏览器会弹出安全提示，接受后即转到 CAS 的登录页面，如图 2 所示：
登录成功后，再重定向到 casTest1 的 WelcomePage 页面，如所示：
可以看到中地址栏里的地址多出了一个 ticket 参数，这就是 CAS 分配给当前应用的 ST(Service Ticket)。
再在同一个浏览器的地址栏中输入
，系统不再提示用户登录，而直接出现如图 4 所示的页面，并且显示在 casTest1 中已经登录过的用户。
重新打开一个浏览器窗口，先输入
，系统要求登录，在登录成功过后，正确显示 casTest2 的页面。之后再在地址栏重新输入
，会直接显示 casTest1 的页面而无需再次登录。
本文介绍了 CAS 单点登录解决方案的原理，并结合实例讲解了在 Tomcat 中使用 CAS 的配置、部署方法以及效果。CAS 是作为开源单点登录解决方案的一个不错选择，更多的使用细节可以参考 CAS 官方网站。
有关 CAS 方面的信息， 请参考。
浏览，与社区分享 Java 技术。
转自：IBM开发者社区
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：987847次
积分：15965
积分：15965
排名：第198名
原创：563篇
转载：290篇
评论：240条
(1)(7)(3)(4)(5)(13)(7)(14)(37)(2)(27)(16)(2)(6)(10)(1)(1)(6)(9)(10)(2)(1)(12)(12)(3)(9)(14)(5)(2)(4)(4)(22)(12)(9)(3)(10)(19)(28)(13)(20)(8)(16)(21)(12)(36)(20)(32)(11)(7)(4)(11)(2)(2)(4)(32)(31)(15)(21)(8)(10)(36)(24)(28)(44)(7)(7)(8)(5)(1)(1)(7)编写你自己的单点登录（SSO）服务 1
1 什么是单点登陆
单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
较大的企业内部，一般都有很多的业务支持系统为其提供相应的管理和IT服务。例如财务系统为财务人员提供财务的管理、计算和报表服务；人事系统为人事部门提供全公司人员的维护服务；各种业务系统为公司内部不同的业务提供不同的服务等等。这些系统的目的都是让计算机来进行复杂繁琐的计算工作，来替代人力的手工劳动，提高工作效率和质量。这些不同的系统往往是在不同的时期建设起来的，运行在不同的平台上；也许是由不同厂商开发，使用了各种不同的技术和标准。如果举例说国内一著名的IT公司（名字隐去），内部共有60多个业务系统，这些系统包括两个不同版本的SAP的ERP系统，12个不同类型和版本的数据库系统，8个不同类型和版本的操作系统，以及使用了3种不同的防火墙技术，还有数十种互相不能兼容的协议和标准，你相信吗？不要怀疑，这种情况其实非常普遍。每一个应用系统在运行了数年以后，都会成为不可替换的企业IT架构的一部分，如下图所示。
随着企业的发展，业务系统的数量在不断的增加，老的系统却不能轻易的替换，这会带来很多的开销。其一是管理上的开销，需要维护的系统越来越多。很多系统的数据是相互冗余和重复的，数据的不一致性会给管理工作带来很大的压力。业务和业务之间的相关性也越来越大，例如公司的计费系统和财务系统，财务系统和人事系统之间都不可避免的有着密切的关系。
为了降低管理的消耗，最大限度的重用已有投资的系统，很多企业都在进行着企业应用集成（EAI）。企业应用集成可以在不同层面上进行：例如在数据存储层面上的&数据大集中&，在传输层面上的&通用数据交换平台&，在应用层面上的&业务流程整合&，和用户界面上的&通用企业门户&等等。事实上，还用一个层面上的集成变得越来越重要，那就是&身份认证&的整合，也就是&单点登录&。
通常来说，每个单独的系统都会有自己的安全体系和身份认证系统。整合以前，进入每个系统都需要进行登录，这样的局面不仅给管理上带来了很大的困难，在安全方面也埋下了重大的隐患。下面是一些著名的调查公司显示的统计数据：
用户每天平均 16 分钟花在身份验证任务上 - 资料来源： IDS
频繁的 IT 用户平均有 21 个密码 - 资料来源： NTA Monitor Password Survey
49% 的人写下了其密码，而 67% 的人很少改变它们
每 79 秒出现一起身份被窃事件 - 资料来源：National Small Business Travel Assoc
全球欺骗损失每年约 12B - 资料来源：Comm Fraud Control Assoc
到 2007 年，身份管理市场将成倍增长至 $4.5B - 资料来源：IDS
使用&单点登录&整合后，只需要登录一次就可以进入多个系统，而不需要重新登录，这不仅仅带来了更好的用户体验，更重要的是降低了安全的风险和管理的消耗。请看下面的统计数据：
提高 IT 效率：对于每 1000 个受管用户，每用户可节省$70K
帮助台呼叫减少至少1/3，对于 10K 员工的公司，每年可以节省每用户 $75，或者合计 $648K
生产力提高：每个新员工可节省 $1K，每个老员工可节省 $350 ?资料来源：Giga
ROI 回报：7.5 到 13 个月 ?资料来源：Gartner
另外，使用&单点登录&还是SOA时代的需求之一。在面向服务的架构中，服务和服务之间，程序和程序之间的通讯大量存在，服务之间的安全认证是SOA应用的难点之一，应此建立&单点登录&的系统体系能够大大简化SOA的安全问题，提高服务之间的合作效率。
2 单点登陆的技术实现机制
随着SSO技术的流行，SSO的产品也是满天飞扬。所有著名的软件厂商都提供了相应的解决方案。在这里我并不想介绍自己公司（Sun Microsystems）的产品，而是对SSO技术本身进行解析，并且提供自己开发这一类产品的方法和简单演示。有关我写这篇文章的目的，请参考我的博客（）。
单点登录的机制其实是比较简单的，用一个现实中的例子做比较。颐和园是北京著名的旅游景点，也是我常去的地方。在颐和园内部有许多独立的景点，例如&苏州街&、&佛香阁&和&德和园&，都可以在各个景点门口单独买票。很多游客需要游玩所有德景点，这种买票方式很不方便，需要在每个景点门口排队买票，钱包拿进拿出的，容易丢失，很不安全。于是绝大多数游客选择在大门口买一张通票（也叫套票），就可以玩遍所有的景点而不需要重新再买票。他们只需要在每个景点门口出示一下刚才买的套票就能够被允许进入每个独立的景点。
单点登录的机制也一样，如下图所示，当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录（1）；根据用户提供的登录信息，认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭据－－ticket（2）；用户再访问别的应用的时候（3，5）就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行效验，检查ticket的合法性（4，6）。如果通过效验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。
从上面的视图可以看出，要实现SSO，需要以下主要的功能：
所有应用系统共享一个身份认证系统。统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。
所有应用系统能够识别和提取ticket信息要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。
上面的功能只是一个非常简单的SSO架构，在现实情况下的SSO有着更加复杂的结构。有两点需要指出的是：
单一的用户信息数据库并不是必须的，有许多系统不能将所有的用户信息都集中存储，应该允许用户信息放置在不同的存储中，如下图所示。事实上，只要统一认证系统，统一ticket的产生和效验，无论用户信息存储在什么地方，都能实现单点登录。
统一的认证系统并不是说只有单个的认证服务器，如下图所示，整个系统可以存在两个以上的认证服务器，这些服务器甚至可以是不同的产品。认证服务器之间要通过标准的通讯协议，互相交换认证信息，就能完成更高级别的单点登录。如下图，当用户在访问应用系统1时，由第一个认证服务器进行认证后，得到由此服务器产生的ticket。当他访问应用系统4的时候，认证服务器2能够识别此ticket是由第一个服务器产生的，通过认证服务器之间标准的通讯协议（例如SAML）来交换认证信息，仍然能够完成SSO的功能。
3 WEB-SSO的实现
随着互联网的高速发展，WEB应用几乎统治了绝大部分的软件应用系统，因此WEB-SSO是SSO应用当中最为流行。WEB-SSO有其自身的特点和优势，实现起来比较简单易用。很多商业软件和开源软件都有对WEB-SSO的实现。其中值得一提的是OpenSSO （），为用Java实现WEB-SSO提供架构指南和服务指南，为用户自己来实现WEB-SSO提供了理论的依据和实现的方法。
为什么说WEB-SSO比较容易实现呢？这是有WEB应用自身的特点决定的。
众所周知，Web协议（也就是HTTP）是一个无状态的协议。一个Web应用由很多个Web页面组成，每个页面都有唯一的URL来定义。用户在浏览器的地址栏输入页面的URL，浏览器就会向Web Server去发送请求。如下图，浏览器向Web服务器发送了两个请求，申请了两个页面。这两个页面的请求是分别使用了两个单独的HTTP连接。所谓无状态的协议也就是表现在这里，浏览器和Web服务器会在第一个请求完成以后关闭连接通道，在第二个请求的时候重新建立连接。Web服务器并不区分哪个请求来自哪个客户端，对所有的请求都一视同仁，都是单独的连接。这样的方式大大区别于传统的（Client/Server）C/S结构,在那样的应用中，客户端和服务器端会建立一个长时间的专用的连接通道。正是因为有了无状态的特性，每个连接资源能够很快被其他客户端所重用，一台Web服务器才能够同时服务于成千上万的客户端。
但是我们通常的应用是有状态的。先不用提不同应用之间的SSO，在同一个应用中也需要保存用户的登录身份信息。例如用户在访问页面1的时候进行了登录，但是刚才也提到，客户端的每个请求都是单独的连接，当客户再次访问页面2的时候，如何才能告诉Web服务器，客户刚才已经登录过了呢？浏览器和服务器之间有约定：通过使用cookie技术来维护应用的状态。Cookie是可以被Web服务器设置的字符串，并且可以保存在浏览器中。如下图所示，当浏览器访问了页面1时，web服务器设置了一个cookie，并将这个cookie和页面1一起返回给浏览器，浏览器接到cookie之后，就会保存起来，在它访问页面2的时候会把这个cookie也带上，Web服务器接到请求时也能读出cookie的值，根据cookie值的内容就可以判断和恢复一些用户的信息状态。
Web-SSO完全可以利用Cookie结束来完成用户登录信息的保存，将浏览器中的Cookie和上文中的Ticket结合起来，完成SSO的功能。
为了完成一个简单的SSO的功能，需要两个部分的合作：
统一的身份认证服务。
修改Web应用，使得每个应用都通过这个统一的认证服务来进行身份效验。
3.1 Web SSO 的样例
根据上面的原理，我用J2EE的技术（JSP和Servlet）完成了一个具有Web-SSO的简单样例。样例包含一个身份认证的服务器和两个简单的Web应用，使得这两个 Web应用通过统一的身份认证服务来完成Web-SSO的功能。此样例所有的源代码和二进制代码都可以从本网站下载。
样例下载、安装部署和运行指南：
Web-SSO的样例是由三个标准Web应用组成，压缩成三个zip文件，从本网站中下载。其中SSOAuth（）是身份认证服务；SSOWebDemo1（）和SSOWebDemo2（）是两个用来演示单点登录的Web应用。这三个Web应用之所以没有打成war包，是因为它们不能直接部署，根据读者的部署环境需要作出小小的修改。样例部署和运行的环境有一定的要求，需要符合Servlet2.3以上标准的J2EE容器才能运行（例如Tomcat5,Sun Application Server 8, Jboss 4等）。另外，身份认证服务需要JDK1.5的运行环境。之所以要用JDK1.5是因为笔者使用了一个线程安全的高性能的Java集合类&ConcurrentMap&，只有在JDK1.5中才有。
这三个Web应用完全可以单独部署，它们可以分别部署在不同的机器，不同的操作系统和不同的J2EE的产品上，它们完全是标准的和平台无关的应用。但是有一个限制，那两台部署应用（demo1、demo2）的机器的域名需要相同，这在后面的章节中会解释到cookie和domain的关系以及如何制作跨域的WEB-SSO
解压缩SSOAuth.zip文件，在/WEB-INF/下的web.xml中请修改&domainname&的属性以反映实际的应用部署情况，domainname需要设置为两个单点登录的应用（demo1和demo2）所属的域名。这个domainname和当前SSOAuth服务部署的机器的域名没有关系。我缺省设置的是&.&。如果你部署demo1和demo2的机器没有域名，请输入IP地址或主机名（如localhost），但是如果使用IP地址或主机名也就意味着demo1和demo2需要部署到一台机器上了。设置完后，根据你所选择的J2EE容器，可能需要将SSOAuth这个目录压缩打包成war文件。用&jar -cvf SSOAuth.war SSOAuth/&就可以完成这个功能。
解压缩SSOWebDemo1和SSOWebDemo2文件，分别在它们/WEB-INF/下找到web.xml文件，请修改其中的几个初始化参数&init-param&&param-name&SSOServiceURL&/param-name&&param-value&&/param-value&&/init-param&&init-param&&param-name&SSOLoginPage&/param-name&&param-value&&/param-value&&/init-param&将其中的SSOServiceURL和SSOLoginPage修改成部署SSOAuth应用的机器名、端口号以及根路径（缺省是SSOAuth）以反映实际的部署情况。设置完后，根据你所选择的J2EE容器，可能需要将SSOWebDemo1和SSOWebDemo2这两个目录压缩打包成两个war文件。用&jar -cvf SSOWebDemo1.war SSOWebDemo1/&就可以完成这个功能。
请输入第一个web应用的测试URL（test.jsp）,例如http://wangyu.:8080/ SSOWebDemo1/test.jsp，如果是第一次访问，便会自动跳转到登录界面，如下图
使用系统自带的三个帐号之一登录（例如，用户名：wangyu,密码：wangyu），便能成功的看到test.jsp的内容：显示当前用户名和欢迎信息。
请接着在同一个浏览器中输入第二个web应用的测试URL（test.jsp）,例如http://wangyu.:8080/ SSOWebDemo2/test.jsp。你会发现，不需要再次登录就能看到test.jsp的内容，同样是显示当前用户名和欢迎信息，而且欢迎信息中明确的显示当前的应用名称（demo2）。
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：330266次
积分：6392
积分：6392
排名：第1144名
原创：301篇
转载：29篇
评论：98条
(1)(1)(1)(2)(2)(3)(4)(4)(1)(4)(3)(2)(1)(1)(3)(3)(6)(15)(17)(1)(2)(6)(3)(10)(8)(16)(19)(14)(3)(28)(8)(4)(2)(1)(2)(3)(2)(20)(20)(1)(4)(1)(3)(1)(4)(6)(9)(14)(13)(13)(13)(1)(1)