CAS配置学习+CAS整合Spring Securtiy配置学习（一）

考完期末试后，就开始做一个手机音频项目。该项目分为几个版本：web、wap、client。我主要负责web版本的。在web版本的需求文档里要求使用CAS单点登录，所以我就花了三四天去研究并使用这个东西。三四天，我自己觉得时间花的不算多，毕竟在此之前我对单点登录了解甚少，自己的水平也还不够高。

 

为了让还没了解过单点登录的人，能够容易读懂这篇文章，在这里简单介绍一下单点登录是什么。单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。（来源于百度百科的解释） 笼统、简单的说，就是有几个相互信任的应用系统，分别为A、B、C、D……，只要登录其中任意一个，就可以随意访问另外的几个而无需再登录。

 

而CAS就是实现单点登录的一个开源项目，其中包括CAS Server和CAS Client。CAS Server（CAS服务器）是需要独立部署的web应用，主要负责对用户的认证工作。CAS Client（CAS客户端）支持很多开发语言，包括Java、.net、PHP、Ruby等，这里所谓的CAS客户端是指单点登录系统中的各个web应用，负责处理对客户端受保护资源的访问请求，需要登录时，重定向到CAS Server。

下图为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 官方网站上的相关文档。

 

准备工作：

要先在CAS官网下载CAS Server和CAS Client，我使用的分别是cas-server-3.4.11-release.zip和cas-client-3.2.1-release.zip。

CAS Server 是一套基于 Java 实现的服务，该服务以一个 Java Web Application 单独部署在与 servlet2.3 兼容的 Web 服务器上，另外，由于 Client 与 CAS Server 之间的交互采用 Https 协议，因此部署 CAS Server 的服务器还需要支持 SSL 协议。当 SSL 配置成功过后，像普通 Web 应用一样将 CAS Server 部署在服务器上就能正常运行了，不过，在真正使用之前，还需要扩展验证用户的接口。

我使用的是TOMCAT 7.0.23，要先在tomcat上配置好https协议的使用。

配置tomcat的https协议：（方法部分转自网上）

1.使用keytool生成证书库文件
在命令行窗口上执行下列命令：
>keytool -genkey -alias tomcat -keyalg RSA -keysize 1024 -validity 365 -keystore tomcat.keystore
会在当前目录下生成文件tomcat.keystore。记住当时输入的密码（假设为123456）。另外，输入的名字要为服务器所在计算机的ip地址或者域名，如果服务器在本机，就使用localhost，不然客户端反问时会报No name matching localhost found异常。
注：keytool文件是在Java的bin目录下。
2.将生成的tomcat.keystore文件放在TOMCAT/conf下。
3.修改server.xml文件：
去掉下面SSL Connector的注释,修改为如下：
<!-- Define an SSL HTTP/1.1 Connector on port 8443 -->

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"

               maxThreads="200" scheme="https" secure="true"

               clientAuth="false" sslProtocol="TLS"       

               keystoreFile="conf/tomcat.keystore"

               keystorePass="123456"/>

参数说明：
clientAuth
如果想要Tomcat为了使用这个socket而要求所有SSL客户出示一个客户证书，置该值为true。
keystoreFile
如果创建的keystore文件不在Tomcat认为的缺省位置（一个在Tomcat运行的home目录下的叫.keystore的文件），则加上该属性。可以指定一个绝对路径或依赖$CATALINA_BASE环境变量的相对路径。
keystorePass
如果使用了一个与Tomcat预期不同的keystore（和证书）密码，则加入该属性。
keystoreType
如果使用了一个PKCS12 keystore，加入该属性。有效值是JKS和PKCS12。
sslProtocol
socket使用的加密/解密协议。如果使用的是Sun的JVM，则不建议改变这个值。据说IBM的1.4.1版的TLS协议的实现和一些流行的浏览器不兼容。这种情况下，使用SSL。
ciphers
此socket允许使用的被逗号分隔的密码列表。缺省情况下，可以使用任何可用的密码。
algorithm
使用的X509算法。缺省为Sun的实现（SunX509）。对于IBM JVMS应该使用ibmX509。对于其它JVM，参考JVM文档取正确的值。
truststoreFile
用来验证客户证书的TrustStore文件。
truststorePass
访问TrustStore使用的密码。缺省值是keystorePass。
truststoreType
如果使用一个不同于正在使用的KeyStore的TrustStore格式，加入该属性。有效值是JKS和PKCS12。
4.重新启动TOMCAT，访问https://localhost:8443
一般情况下打开页面之前会有证书安全警告，选择信任就可以了！

 

由于相关内容很多，所以要分为几篇文章！接下来请看“CAS配置学习+CAS整合Spring Securtiy配置学习（二）”