Yale CAS介绍与简单示例

最新推荐文章于 2024-09-14 21:06:55 发布

xiaowu218

最新推荐文章于 2024-09-14 21:06:55 发布

阅读量563

点赞数

分类专栏： java 文章标签： server credentials tomcat service jvm java

java 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

CAS(Central Authentication Service) 是 Yale 大学发起的一个开源项目。

从结构体系看， CAS 包含两部分：

l CAS Server

CAS Server 负责完成对用户的认证工作， CAS Server 需要独立部署，有不止一种 CAS Server 的实现， Yale CAS Server 和 ESUP CAS Server 都是很不错的选择。

CAS Server 会处理用户名 / 密码等凭证 (Credentials) ，它可能会到数据库检索一条用户帐号信息，也可能在 XML 文件中检索用户密码，对这种方式， CAS 均提供一种灵活但同一的接口 / 实现分离的方式， CAS 究竟是用何种认证方式，跟 CAS 协议是分离的，也就是，这个认证的实现细节可以自己定制和扩展。

l CAS Client

CAS Client 负责部署在客户端（注意，我是指 Web 应用），原则上， CAS Client 的部署意味着，当有对本地 Web 应用的受保护资源的访问请求，并且需要对请求方进行身份认证， Web 应用不再接受任何的用户名密码等类似的 Credentials ，而是重定向到 CAS Server 进行认证。

目前， CAS Client 支持（某些在完善中）非常多的客户端，包括 Java 、 .Net 、 ISAPI 、 Php 、 Perl 、 uPortal 、 Acegi 、 Ruby 、 VBScript 等客户端，几乎可以这样说， CAS 协议能够适合任何语言编写的客户端应用。

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 的方法上虽然有所区别，但是，最终都可以实现这样一个目的——免去多次登录的麻烦。

下面，我们看看 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 ，直接访问 helloservice 应用，它被立即重定向到 CAS Server 进行认证， User 可能感觉到浏览器在 helloservcie 和 casserver 之间重定向，但 User 是看不到， CAS Client 和 CAS Server 相互间的 Service Ticket 核实 (Validation) 过程。当 CAS Server 告知 CAS Client 用户 Service Ticket 对应确凿身份， CAS Client 才会对当前 Request 的用户进行服务。

CAS 可以很简单的实现跨域的 SSO ，因为，单点被控制在 CAS Server ，用户最有价值的 TGC-Cookie 只是跟 CAS Server 相关， CAS Server 就只有一个，因此，解决了 cookies 不能跨域的问题。

回到 CAS 的基础协议图，当 Step3 完成之后， CAS Server 会向 User 发送一个 Ticket granting cookie (TGC) 给 User 的浏览器，这个 Cookie 就类似 Kerberos 的 TGT ，下次当用户被 Helloservice2 重定向到 CAS Server 的时候， CAS Server 会主动 Get 到这个 TGC cookie ，然后做下面的事情：

如果 User 的持有 TGC 且其还没失效，那么就走基础协议图的 Step4 ，达到了 SSO

简单示例

此示例CAS服务器与CAS客户端使用相同的Tomcat

1 配置WEB服务器的HTTPS服务

1.1 开启Tomcat的HTTPS服务

环境：Windows XP + JDK 1.6 + apache-tomcat-5.5.23

1）生成服务器端密钥并保存到密钥库文件中

%JAVA_HOME%/bin/keytool -genkey -alias tomcat -keyalg RSA -keystore keystore.jks

-alias 自定义别名，此处取tomcat；

-keyalg 主要两种方式：RSA采用MD5加RSA算法加密密钥，DSA 采用SHA1加DSA算法加密密钥，此处采用RSA；

-keystore 密钥库文件。

注意：当用户输入keystore.jks文件的保护密码后（与JVM信任库密码一致：changeit），系统提示“您的名字与姓氏是什么”时，此时应输入本机的域名，如shazhenzhong或shazhenzhong，在此我们输入shazhenzhong，最后就用https://shazhenzhong:8443来测试配置是否成功。域名配置参见：C:/WINDOWS/system32/drivers/etc下的Hosts文件(增加一个本地名描述127.0.0.1 shazhenzhong)。

如果客户端应用与CAS server不在同一JVM中，请执行2）和3）：

2）导出服务端证书

%JAVA_HOME%/bin/keytool -export -file myserver.cert -alias tomcat -keystore keystore.jks

由keystore.jks文件中的tomcat别名项导出myserver.cert服务端证书。

3）将服务端证书导入JVM信任库中

keytool -import -trustcacerts -alias tomcat -file myserver.cert -keystore C:/"Program Files"/Java/jdk1.6.0_10/jre/lib/security/cacerts

将服务端证书myserver.cert以别名tomcat导入JVM的信任库中，JVM信任库文件cacerts的默认密码为changeit。

注：删除与查看客户端证书，在证书误操作后可以调整

keytool -delete -alias tomcat -keystore C:/"Program Files"/Java/jdk1.6.0_10/jre/lib/security/cacerts
keytool -list -keystore C:/"Program Files"/Java/jdk1.6.0_10/jre/lib/security/cacerts >t.txt

4）配置Tomcat的SSL项

把最初生成的keystore.jks复制到%TOMCAT_HOME%/conf下。

找到%TOMCAT_HOME%/conf/server.xml文件，解开SSL的注释。

实例配置如下：