单点登录系列之二---初步认识CAS

最新推荐文章于 2024-03-05 09:28:53 发布

王者天下ii

最新推荐文章于 2024-03-05 09:28:53 发布

阅读量653

点赞数

文章标签： CAS单点登录

本文链接：https://blog.csdn.net/yan470925731/article/details/8934818

版权

1.CAS介绍
　　CAS（Central Authentication Service，即中央认证服务），是Yale大学发起的一个开源单点登录项目，旨在为应用系统提供一种可靠的单点登录方法。于2004年12月正式成为JA-SIG的一个项目。

2.CAS特点

开源的企业级单点登录解决方案
CAS被设计成一个独立的Web应用程序(cas.war)
CAS Client支持非常多的客户端(这里指单点登录系统中的各个 Web 应用)，包括Java、.Net、PHP、Perl、Apache、uPortal等
能够与uPortal, BlueSocket, TikiWiki, Mule, Liferay, Moodle等集成使用。

3.CAS 原理和协议
　　从结构上看，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 官方网站上的相关文档。
以上大部分内容摘自：http://www.ibm.com/developerworks/cn/opensource/os-cn-cas/index.html

4.准备工作
JA-SIG官方网站：http://www.jasig.org/cas
CAS Server下载地址：http://www.jasig.org/cas/download
CAS Client下载地址：http://downloads.jasig.org/cas-clients/

官方CAS Client for Java 3.1文档：https://wiki.jasig.org/display/CASC/CAS+Client+for+Java+3.1
Tomcat 6下载地址：http://archive.apache.org/dist/tomcat/tomcat-6/

在此，笔者分别使用cas-server-3.3.3、cas-client-3.1.10(支持单点登出)和Tomcat 6.0.18。

5.部署CAS Server
　　解压cas-server-3.3.3包，将modules/cas-server-webapp-3.3.3.war复制到Tomcat的webapps目录下，并重命名为cas3.war，启动Tomcat。启动完毕后，访问地址：http://localhost:8080/cas3/login，我们将看到中央认证服务中用于收集用户凭证的入口界面：

　　默认时，只要用户输入相同的用户名和密码，就可以登录到CAS服务器中。比如输入用户名/密码：admin/admin，单击“登录”后将成功进入以下成功提示界面：

　　当成功登录到CAS服务器后，浏览器会存储CAS服务器返回的一个Cookie，其名字默认为“CASTGC”。当目标Web应用实施了CAS SSO之后，它们便需要借助于这一Cookie实现Web SSO会话。由此建立了用户与CAS服务器之间的信任关系。

　　此时，如果用户需要退出，可以通过http://localhost:8080/cas3/logout退出CAS服务器。退出操作将导致浏览器中存在的CASTGC Cookie被销毁，即销毁CAS与当前用户已建立的信任关系（Web SSO会话）。事实上，由于我们使用的是HTTP协议操控logout，因此浏览器中的CASTGC Cookie并未被销毁。如果借助于HTTPS操控logout，则浏览器中的CASTGC Cookie便会被销毁掉。在未启用HTTPS时，如果使用IE，可以通过关闭浏览器以达到销毁CASTGC Cookie的目的。