CAS原理介绍

·        所有应用系统能够识别和提取ticket信息 

 

系统组件

CAS系统架构包括CAS Server和CAS Clients，它们是通过各种协议进行通信的两个物理组件。

证书生成

由于CAS服务全程使用HTTPS加密通讯协议，所以必须配置证书以达到此目的，否则服务将不会正常服务。

 

CAS 原理和协议

从结构上看，CAS 包含两个部分： CAS Server 和 CAS Client。CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CASServer。图1 是 CAS 最基本的协议过程：

图 1. CAS 基础协议

 

 

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

 

2.2.2 CAS 如何实现 SSO

       当我们的 Web 时代还处于初级阶段的时候， SSO 是通过共享 cookies 来实现，比如，下面三个域名要做 SSO ：

http://www.blogjava.net

http://www.matrix.org.cn

http://www.csdn.net

如果通过 CAS 来集成这三个应用，那么，这三个域名都要做一些域名映射，

http://blogjava.cas.org

http://matrix.cas.org

http://csdn.cas.org

因为是同一个域，所以每个站点都能够共享基于 cas.org 的 cookies 。这种方法原始，不灵活而且有不少安全隐患，已经被抛弃了。

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

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

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

2，              如果 TGC 失效，那么用户还是要重新认证 ( 走基础协议图的 Step3) 。