1     前言

单点登录(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 等。

2     CAS的原理

2.1               从结构体系看， 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 协议能够适合任何语言编写的客户端应用。

2.2               协议

从CAS v1到现在的CAS v3，整个协议的基础思想都是基于票据方式。

CAS v1非常原始，传送一个用户名”yes\ndavid.turing”的方式，CAS v2开始使用了XML规范，大大增强了可扩展性，CAS v3开始使用AOP技术，让Spring爱好者可以轻松配置CAS Server到现有的应用环境中。

CAS是通过TGT(Ticket Granting Ticket)来获取ST(Service Ticket)，通过ST来访问服务，而CAS也有对应TGT，ST的实体，而且他们在保护TGT的方法上虽然有所区别，但是，最终都可以实现这样一个目的——免去多次登录的麻烦。

TGT + S = ST ？(可能是这样)

下面，我们看看CAS的基本协议框架：

CAS基础模式

上图是一个最基础的 CAS 协议， CAS Client 以 Filter 方式保护 Web 应用的受保护资源，过滤从客户端过来的每一个 Web 请求，同时， CAS Client 会分析 HTTP 请求中是否包请求 Service Ticket(上图中的 Ticket) ，如果没有，则说明该用户是没有经过认证的，于是， CAS Client 会重定向用户请求到 CAS Server ( Step 2 )。 Step 3 是用户认证过程，如果用户提供了正确的 Credentials ， CAS Server 会产生一个随机的 Service

Ticket ，然后，缓存该 Ticket ，并且重定向用户到 CAS Client (附带刚才产生的 Service Ticket )， Service Ticket 是不可以伪造的，最后， Step 5 和 Step6 是 CAS Client 和 CAS Server 之间完成了一个对用户的身份核实，用 Ticket 查到 Username ，因为 Ticket 是 CAS Server 产生的，因此，所以 CAS Server 的判断是毋庸置疑的。

该协议完成了一个很简单的任务，就是 User(david.turing) 打开 IE ，直接访问 clientweb 应用，它被立即重定向到 CAS Server 进行认证， User 可能感觉到浏览器在 clientweb 和 casserver 之间重定向，但 User 是看不到， CAS Client 和 CAS Server 相互间的 Service Ticket 核实 (Validation) 过程。当 CAS Server 告知 CAS Client 用户 Service Ticket 对应确凿身份， CAS

Client 才会对当前 Request 的用户进行服务。

CAS浏览器请求序列图

CAS服务器端登陆流程图

3     CAS Server端配置

Server端主要是需要安装Server的WAR包，并运行起来。由于 Client 与 CAS Server 之间的交互采用 Https 协议，因此部署 CAS Server 的服务器还需要支持 SSL 协议。当 SSL 配置成功过后，(也可以不使用SSL协议，而使用普通方式)像普通 Web 应用一样将 CAS Server 部署在服务器上就能正常运行了，不过，在真正使用之前，还需要扩展验证用户的接口。

3.1               增加tomcat的SSL配置

生成key的步骤省略，参看这里，介绍的很详细。之后配置tomcat的server.xml文件，增加如下配置，将JDK的cacerts配置到tomcat的信任库中：

修改%TOMCAT_HOME%/conf/server.xml

去掉下面SSL HTTP那个注释，修改为如下：

Xml代码

SSLEnabled="true"

maxThreads="150"

scheme="https"

secure="true"

clientAuth="false"

sslProtocol="TLS"

keystoreFile="conf/tomcat.keystore"

keystorePass="123456" />

keystoreFile 是tomcat.keystore放置的位置，keystorePass是前面生成tomcat.keystore所设置的密码(123456)

也可取消CAS的HTTPS登录，需要设置几个地方。可以参考这里。

概括来说就是查找Secure字符，找到两个设置的地方，把true改成false;

修改deployerConfigContext.xml

添加p:requireSecure="false"

客户端可能也需要进行修改。

3.2     扩展认证接口

我这里的Cas-server的版本是 3.4.2.1

目前，部署下载的server中module里的war包到tomcat中，启动tomcat，然后访问：https://localhost:8443/cas ，如果能出现正常的 CAS 登录页面，则说明 CAS Server 已经部署成功。

虽然 CAS Server 已经部署成功，但这只是一个缺省的实现，在默认的server界面，只要输入用户名和密码相同，就可以登录。当然，在实际使用的时候，这样做肯定是不行的，还需要根据实际概况做扩展和定制，最主要的是扩展认证 (Authentication) 接口和 CAS Server 的界面。

我们通常都会使用jdbc连接数据库进行认证，这种情况，用户名和密码被保存在数据库的某个表中。需要进行如下配置。

3.2.1         配置jdbc sql语句认证方式

用编辑器打开/webapps/cas-server-3.1.1/WEB-INF/deployerConfigContext.xml，找到如下xml,并注释掉该代码：

在下面填写如下代码：

并添加一个bean：

com.mysql.jdbc.Driver

jdbc:mysql://localhost:3306/test

test

test

假设使用数据库密码sd5加密，则增加配置如下：(红色部分是sd5加密配置)

注意，再次部署，还需要增加几个包，做为依赖，如果使用maven，可以加入如下代码：

mysql

mysql-connector-java

5.1.12

org.apache.openejb

commons-dbcp-all

1.3-r699049

如果您不使用maven管理的话，可以下载相应的包，并拷贝到WEB-INF/lib/中，重新启动tomcat即可。

创建表

mysql> create table user(id int,username char(100) NOT NULL,password char(100) NOT NULL,PRIMARY KEY (id));

mysql> insert into user values(2,'admin','admin123');

3.3               RESTFul 配置

CAS提供了 RestFul API ，Restlet配置如下：

org.jasig.cas

cas-server-integration-restlet

3.4.11

jar

然后再在 web.xml 中加入:

restlet

com.noelios.restlet.ext.spring.RestletFrameworkServlet

1

restlet

/v1/*

3.4              SPRING security 集成

Spring security  3.1.x的首页讲了如何配置它到您的项目，在线官方文档请点击这里；跟CAS相关的章节请点击这里。3.0.X的SPRING官方也有讲解，再这里，讲的没有3.1.X的内容多。

CAS官方网站也给了个例子，用于于Spring security集成，不过讲的也不是很详细，可以点击这里查看。

国内的找了两篇写的可以的，点击 链接1，链接2 来查看。

3.5 关于登出

3.6 登录验证之添加“用户不存在”错误信息

以上都是Server端的配置，下一篇将会总结客户端的配置。

4.问题

4.1证书的问题

在打证书的时候，输入了

您的名字与姓氏是什么？

经测试发现..如果caserver与单点服务在同一台电脑上,用key里注册的localhost访问是不会有问题的.但是如果不在同一台电脑上..内网访问也会出错!

所以这里不主张用localhost,可以用ip注册,内网访问用ip将不会有问题.(可是实际上CAS中也是不主张用IP来注册的)

另一个域名,将localhost改写成caserver单点所在服务器上的计算机名(右击我的电脑,属性,计算机名).测试通过!(这种方式虽然没有问题，但是必须把部署的机器名称改为此认证中的名称，比如master)

4.2 客户端只能使用域名来对中心发出申请，而不能使用IP。