CAS实现SSO单点登录原理
1、CAS 简介
简单的 SSO 的体系中，会有下面三种角色：
1、User（多个）
2、Web 应用（多个）
3、SSO 认证中心（1个）
虽然 SSO 实现模式千奇百怪，但万变不离其宗：
1、Web 应用不处理 User 的登录，否则就是多点登陆了，所有的登录都在 SSO 认证中心进行。
2、SSO 认证中心通过一些方法来告诉 Web 应用当前访问用户究竟是不是张三/李四。
3、SSO 认证中心和所有的 Web 应用建立一种信任关系，SSO 认证中心对用户身份正确性的判断会通过某种方法告之 Web 应用，而且判断结果必须被 Web 应用信任。
1.1、What is CAS
CAS（Central Authentication Service）是 Yale 大学发起的一个企业级的、开源的项目，旨在为 Web 应用系统提供一种可靠的单点登录解决方法（属于 Web SSO）。
CAS 开始于 2001 年，并在 2004 年 12 月正式成为 JA-SIG 的一个项目。
1.2、主要特性
1、开源的、多协议的 SSO 解决方案；Protocols：Custom Protocol、CAS、OAuth、OpenID、RESTful API、SAML1.1、SAML2.0等。
2、支持多种认证机制：Active Directory、JAAS、JDBC、LDAP、X.509 Certificates等；
3、安全策略：使用票据（Ticket）来实现支持的认证协议；
4、支持授权：可以决定哪些服务可以请求和验证服务票据（Service Ticket）；
5、提供高可用性：通过把认证过的状态数据存储在 TicketRegistry 组件中，这些组件有很多支持分布式环境的实现，如：BerkleyDB、Default、EhcacheTicketRegistry、JDBCTicketRegistry、JBOSS TreeCache、JpaTicketRegistry、MemcacheTicketRegistry等；
6、支持多种客户端：Java、.Net、PHP、Perl、Apache, uPortal等。
2、SSO 简介
本文内容主要针对 Web SSO。
2.1、什么是SSO
单点登录（Single Sign-On, 简称 SSO）是目前比较流行的服务于企业业务整合的解决方案之一，SSO 使得在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
2.2、SSO 原理
2.2.1. SSO 体系中的角色
一般SSO体系主要角色有三种：
1、User（多个）
2、Web 应用（多个）
3、SSO 认证中心（1个）
2.2.2. SSO 实现模式的原则
SSO 实现模式一般包括以下三个原则：
1、所有的认证登录都在 SSO 认证中心进行；
2、SSO 认证中心通过一些方法来告诉 Web 应用当前访问用户究竟是不是已通过认证的用户；
3、SSO 认证中心和所有的 Web 应用建立一种信任关系，也就是说 web 应用必须信任认证中心。（单点信任）
2.2.3. SSO 主要实现方式
SSO 的主要实现方式有
1、共享 cookies
基于共享同域的 cookie 是 Web 刚开始阶段时使用的一种方式，它利用浏览同域名之间自动传递 cookies 机制，实现两个域名之间系统令牌传递问题；另外，关于跨域问题，虽然 cookies本身不跨域，但可以利用它实现跨域的 SSO。如：代理、暴露 SSO 令牌值等。
缺点：不灵活而且有不少安全隐患，已经被抛弃。
2、Broker-based(基于经纪人)
这种技术的特点就是，有一个集中的认证和用户帐号管理的服务器。经纪人给被用于进一步请求的电子身份存取。中央数据库的使用减少了管理的代价，并为认证提供一个公共和独立的"第三方"。例如 Kerberos、Sesame、IBM KryptoKnight（凭证库思想)等。Kerberos是由麻省理工大学发明的安全认证服务，已经被 UNIX 和 Windows 作为默认的安全认证服务集成进操作系统。
3、Agent-based（基于代理人）
在这种解决方案中，有一个自动地为不同的应用程序认证用户身份的代理程序。这个代理程序需要设计有不同的功能。比如，它可以使用口令表或加密密钥来自动地将认证的负担从用户移开。代理人被放在服务器上面，在服务器的认证系统和客户端认证方法之间充当一个"翻译"。例如 SSH 等。
4、Token-based
例如 SecureID,WebID，现在被广泛使用的口令认证，比如FTP、邮件服务器的登录认证，这是一种简单易用的方式，实现一个口令在多种应用当中使用。
5、基于网关
6、基于 SAML
SAML(Security Assertion Markup Language，安全断言标记语言）的出现大大简化了 SSO，并被 OASIS 批准为 SSO 的执行标准。开源组织 OpenSAML 实现了 SAML 规范。
3、CAS 的基本原理
3.1、结构体系
从结构体系看，CAS 包括两部分： CAS Server 和 CAS Client。
3.1.1. CAS Server
CAS Server 负责完成对用户的认证工作,需要独立部署,CAS Server会处理用户名/密码等凭证(Credentials)。
3.1.2. CAS Client
负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server进行认证。（原则上，客户端应用不再接受任何的用户名密码等Credentials）。
CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。
3.2、CAS 原理和协议
3.2.1. 基础模式
基础模式 SSO 访问流程主要有以下步骤：
1.访问服务：SSO客户端发送请求访问应用系统提供的服务资源。
2.定向认证：SSO客户端会重定向用户请求到SSO服务器。
3.用户认证：用户身份认证。
4.发放票据：SSO服务器会产生一个随机的Service Ticket。
5.验证票据：SSO服务器验证票据Service Ticket的合法性，验证通过后，允许客户端访问服务。
6.传输用户信息：SSO服务器验证票据通过后，传输用户认证结果信息给客户端。
下面是CAS最基本的协议过程：
基础协议图
如上图：CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护 Web 应用的受保护资源，过滤从客户端过来的每一个 Web 请求，同时，CAS Client 会分析 HTTP 请求中是否包含请求 Service Ticket(ST上图中的Ticket)，如果没有，则说明该用户是没有经过认证的；于是 CAS Client 会重定向用户请求到 CAS Server（Step 2），并传递 Service（要访问的目的资源地址）。Step 3 是用户认证过程，如果用户提供了正确的Credentials，CAS Server随机产生一个相当长度、唯一、不可伪造的Service Ticket，并缓存以待将来验证，并且重定向用户到 Service 所在地址（附带刚才产生的 Service Ticket）,并为客户端浏览器设置一个Ticket Granted Cookie（TGC）；CAS Client 在拿到 Service 和新产生的 Ticket 过后，在 Step 5和 Step6 中与 CAS Server 进行身份核实，以确保 Service Ticket 的合法性。
在该协议中，所有与CAS Server 的交互均采用 SSL 协议，以确保 ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程。但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的（使用 HttpsURLConnection）。
CAS 请求认证时序图如下：
3.2.1. CAS 如何实现 SSO
当用户访问另一个应用的服务再次被重定向到CAS Server 的时候，CAS Server 会主动获到这个 TGC cookie，然后做下面的事情：
1) 如果 User 持有 TGC 且其还没失效，那么就走基础协议图的 Step4，达到了 SSO 的效果；
2) 如果 TGC 失效，那么用户还是要重新认证(走基础协议图的 Step3)。
3.2.2. CAS 代理模式
该模式形式为用户访问 App1，App1又依赖于App2 来获取一些信息，如：User -->App1 -->App2。
这种情况下，假设 App2 也是需要对 User 进行身份验证才能访问，那么，为了不影响用户体验（过多的重定向导致 User 的 IE 窗口不停地闪动)，CAS 引入了一种 Proxy 认证机制，即CAS Client 可以代理用户去访问其它Web应用。
代理的前提是需要 CAS Client拥有用户的身份信息(类似凭据)。之前我们提到的TGC是用户持有对自己身份信息的一种凭据，这里的 PGT 就是 CAS Client 端持有的对用户身份信息的一种凭据。凭借TGC，User可以免去输入密码以获取访问其它服务的 Service Ticket，所以，这里凭借 PGT，Web应用可以代理用户去实现后端的认证，而无需前端用户的参与。
下面为代理应用（helloService）获取 PGT 的过程：（注：PGTURL 用于表示一个 Proxy 服务，是一个回调链接；PGT 相当于代理证； PGTIOU 为取代理证的钥匙，用来与 PGT 做关联关系；）
如上面的 CAS Proxy 图所示，CAS Client 在基础协议之上，在验证 ST 时提供了一个额外的PGT URL(而且是 SSL 的入口)给 CAS Server，使得 CAS Server 可以通过 PGT URL 提供一个 PGT 给 CAS Client。
CAS Client 拿到了 PGT(PGTIOU-85 … ..ti2td)，就可以通过 PGT 向后端 Web 应用进行认证。
下面是代理认证和提供服务的过程：
如上图所示，Proxy 认证与普通的认证其实差别不大，Step1，2 与基础模式的 Step1,2 几乎一样，唯一不同的是，Proxy 模式用的是 PGT 而不是 TGC，是 Proxy Ticket（PT）而不是 Service Ticket。
3.2.3. 辅助说明
CAS 的 SSO 实现方式可简化理解为：1个 Cookie 和N个 Session。 CAS Server创建cookie，在所有应用认证时使用，各应用通过创建各自的 Session 来标识用户是否已登录。
用户在一个应用验证通过后，以后用户在同一浏览器里访问此应用时，客户端应用中的过滤器会在 session 里读取到用户信息，所以就不会去 CAS Server 认证。如果在此浏览器里访问别的 web 应用时，客户端应用中的过滤器在 session 里读取不到用户信息，就会去 CAS Server的login接口认证，但这时CAS Server会读取到浏览器传来的cookie（TGC），所以CAS Server不会要求用户去登录页面登录，只是会根据service参数生成一个Ticket，然后再和web应用做一个验证ticket的交互而已。
3.3、术语解释
CAS 系统中设计了5中票据：TGC、ST、PGT、PGTIOU、PT。
- Ticket-granting cookie(TGC)：存放用户身份认证凭证的 cookie，在浏览器和CAS Server间通讯时使用，并且只能基于安全通道传输（Https），是CAS Server用来明确用户身份的凭证；
- Service ticket(ST)：服务票据，服务的惟一标识码,由CAS Server发出（Http 传送），通过客户端浏览器到达业务服务器端；一个特定的服务只能有一个惟一的ST；
- Proxy-Granting ticket（PGT）：由CAS Server颁发给拥有ST凭证的服务，PGT绑定一个用户的特定服务，使其拥有向CAS Server申请，获得PT的能力；
- Proxy-Granting Ticket I Owe You（PGTIOU）:作用是将通过凭证校验时的应答信息由 CAS Server 返回给 CAS Client，同时，与该 PGTIOU 对应的 PGT 将通过回调链接传给 Web 应用。 Web 应用负责维护PGTIOU与PGT之间映射关系的内容表；
- Proxy Ticket (PT)：是应用程序代理用户身份对目标程序进行访问的凭证；
其它说明如下：
- Ticket Granting ticket(TGT)：票据授权票据，由KDC的AS发放。即获取这样一张票据后，以后申请各种其他服务票据(ST)便不必再向KDC提交身份认证信息(Credentials)；
- Authentication service(AS)---------认证用服务，索取Credentials，发放TGT；
- Ticket-granting service (TGS)---------票据授权服务，索取 TGT，发放ST；
- KDC(Key Distribution Center)----------密钥发放中心；
4、登录流程
4.1、CAS 登录时处理：
第一步：
cas往浏览器增加cookie（ＴＧＣ）
CAS向浏览器送回一个所谓的“内存cookie”。这种cookie并不是真的保存在内存中，而只是浏览器一关闭，cookie就自动过期。这个cookie称为“ticket-granting cookie”，用来表明用户已经成功地登录。
这个Cookie是一个加密的Cookie，其中保存了用户登录的信息。用于以后其它应用客户端登录。
第二步：
cas同时创建一个ticket重定向到原来的cas客户端
认证成功后，CAS服务器创建一个很长的、随机生成的字符串，称为“Ticket”。随后，CAS将这个ticket和成功登录的用户，以及服务联系在一起。这个ticket是一次性使用的一种凭证，它只对登录成功的用户及其服务使用一次。使用过以后立刻失效。
4.2、Cas 客户端应用A的处理
第一步：
收到ticket后，向cas提交验证ticket
Cas客户端收到ticket之后，应用程序需要验证ticket。这是通过将ticket传递给一个校验URL来实现的。校验URL也是CAS服务器提供的。CAS通过校验路径获得了ticket之后，通过内部的数据库对其进行判断。如果判断是有效性，则返回一个NetID给应用程序。随后CAS将ticket作废，并且在客户端留下一个cookie。(谁来创建cookie)
第二步：
ticket验证后创建session以后登录此应用时，没有ticket，但ＩＥ能提供session,从session中取得CASReceipt,并验证如果有效说明已经在此应用认证过，允许访问此应用，到此为止，ＣＡＳ会记录用户已在应用Ａ已经登录
4.3、用户登录到应用B是如何处理
用户进入应用Ｂ时，首先仍然会重定向到CAS服务器。不过此时CAS服务器不再要求用户输入用户名和密码，而是首先自动寻找Cookie，根据Cookie中保存的信息，进行登录。然后，CAS同样给出新的ticket重定向应用Ｂ给cas验证（流程同应用Ａ验证方式），如果验证成功则应用Ｂ创建session记录CASReceipt信息到session中，以后凭此session登录应用Ｂ。
到此为止，ＣＡＳ会记录用户已在应用A和应用B进行登录，但是当用户在应用B退出cas登录时，要通知应用Ａ进行退出，如何通知应用Ａ呢？
登出
CAS server接受请求后，会检测用户的TCG Cookie，把对应的session清除，同时会找到所有通过该TGC sso登录的应用服务器URL提交请求,所有收到请求的应用服务器application会解析这个参数，取得sessionId，根据这个Id取得session后，把session删除。
这样就实现单点登出的功能。
5、CAS 安全性
CAS 的安全性仅仅依赖于SSL。使用的是secure cookie。
5.1. TGC/PGT 安全性
对于一个 CAS 用户来说，最重要是要保护它的TGC，如果TGC不慎被 CAS Server 以外的实体获得，Hacker 能够找到该 TGC，然后冒充 CAS 用户访问所有授权资源。PGT的角色跟TGC是一样的。
从基础模式可以看出，TGC是 CAS Server 通过 SSL 方式发送给终端用户，因此要截取TGC 难度非常大，从而确保 CAS 的安全性。
TGT 的存活周期默认为 120 分钟。
5.2. ST/PT安全性
ST（Service Ticket）是通过 Http 传送的，因此网络中的其他人可以 Sniffer到其他人的Ticket。CAS 通过以下几方面来使 ST 变得更加安全（事实上都是可以配置的）：
1、ST只能使用一次
CAS 协议规定，无论Service Ticket 验证是否成功，CAS Server 都会清除服务端缓存中的该Ticket，从而可以确保一个 Service Ticket不被使用两次。
2、ST在一段时间内失效
CAS 规定ST只能存活一定的时间，然后CAS Server会让它失效。默认有效时间为5分钟。
3、ST是基于随机数生成的
ST 必须足够随机，如果 ST 生成规则被猜出，Hacker就等于绕过CAS认证，直接访问对应的服务。
客户端消息流程
1.第一次访问 http://localhost:8080/A
CLIENT：没票据且SESSION中没有消息所以跳转至CAS
CAS：拿不到TGC故要求用户登录
2. 认证成功后回跳
CAS：通过TGT生成ST发给客户端，客户端保存TGC，并重定向到 http://localhost:8080/A
CLIENT：带有票据所以不跳转只是后台发给CAS验证票据（浏览器中无法看到这一过程）
3. 第一次访问 http://localhost:8080/B
CLIENT：没票据且SESSION中没有消息所以跳转至CAS
CAS：从客户端取出TGC，如果TGC有效则给用户ST并后台验证ST，从而SSO。【如果失效重登录或注销时，怎么通知其它系统更新SESSION信息呢？？
TicketGrantingTicketImpl类grantServiceTicket方法里this.services.put(id,service);可见CAS端已经记录了当前登录的子系统】
4. 再次访问 http://localhost:8080/A
CLIENT：没票据但是SESSION中有消息故不跳转也不用发CAS验证票据，允许用户访问