CAS笔记

需求

多个应用系统需要实现登录功能，并且账号体系是同一套，同时为了提升使用体验（一次登录，即可访问多个相互信任的应用系统），因此需要搭建一套sso系统。sso的基本原理可以参考现实生活中的公园“通票”，一个公园中可能包含多个景区，每个景区需要分别购票才可游览，也可以选择购买通票，有了通票就可以在此多个景区间无障碍通行

选型

前提是尽量避免重复造轮子，考虑使用开源方案。开源方案中较为有名的有opensso和cas。前者源于sun公司（oracle），不过目前此开源项目已经处于inactive状态。后者源于耶鲁大学，有成熟的协议模型

CAS

CAS(Central Authentication Service) 是 Yale 大学发起的一个开源项目，从结构体系来看主要包含两部分：cas server及cas client。前者负责完成对用户的认证以及对受限资源的授权（只能使用https）。后者负责保护受限资源以及从server端识别授权用户。基本结构如下图：



CAS协议基于ticket，完整的协议文档可以参考http://jasig.github.io/cas/4.2.x/protocol/CAS-Protocol-Specification.html，下面对其核心概念做一简介

Service Ticket（st）

被用于client端访问受限资源时身份认证的凭据，登录认证成功后由server端生成并回传给client端

Login Ticket（lt）

在通过用户名密码登录认证时作为认证凭据的一部分，在server端展现登录界面前生成

Ticket-Granting Cookie（tgc）

用于保持sso session的cookie，value是tgt（下面介绍）的key，改cookie为secure cookie

Ticket-Granting Ticket（tgt）

代表包含登录状态的sso session，登录认证成功后由server端生成，后续的st将基于此派发，tgt 的key作为tgc的value存储在浏览器cookie

其他关于proxy service的相关内容需要时再做补充

下面来看一下cas流程的时序图：



配合这张时序图，整个cas的流程、原理和上面介绍的基本概念应该就可以完整的串起来了：

1.在第一次访问应用app1时，由于没有登录会直接跳转到Cas Server去进行登录认证，此时将附带查询参数service在Cas Server的登录地址上，表示登录成功后将要跳转的地址。此时Cas Server检查到没有之前成功登录后生成的SSO Session信息，那么就会引导用户到登录页面进行登录。用户输入信息提交登录请求，Cas Server认证成功后将生成对应的SSO Session，以及名为CASTGC的cookie，该cookie包含用来确定用户SSO Session的Ticket Granting
Ticket（TGT）。之后会生成一个Service Ticket（ST），并将以ticket作为查询参数名，以该ST作为查询参数值跳转到登录时service对应的URL。如： http(s)://domain/app1?ticket=ST-2-59fS6KxvmykibRXyoPJE

2.之后的操作对用户来说都是透明的，即不可见的。app1之后将以service和ticket作为查询参数请求Cas Server对service进行验证，验证通过后Cas Server将返回当前用户的用户名等信息。app1就会给当前用户生成其自身的Session，以后该用户以该Session都可以成功的访问app1，而不需要再去请求Cas Server进行认证。当该用户再去访问app2的时候，由于其在app2上没有对应的Session信息，将会跳转到Cas Server的登录地址，Cas Server此时发现其包含名为CASTGC的cookie，将获取其中包含的TGT来获取对应的SSO
Session，然后会将用户重定向到app2对应的地址，以Service Ticket作为查询参数。之后app2会向Cas Server发送请求校验该Service Ticket，校验成功后app2将建立该用户对应的Session信息，以后该用户以该Session就可以自由的访问app2了

综上所述，我们知道，各系统之间的单点登录是通过Cas Server生成的SSO Session来交流的，而用户与实际的应用系统进行交互的时候，各应用系统将建立单独的Session，以满足用户与该系统的交互需求

部分问题及解决方案

1.证书问题，由于使用https，因此需要证书。开发及测试环境可自行生成证书（java keytool），需要注意的是证书与域名直接关联，因此不可使用ip（否则会在握手阶段产生错误），另外由于不是CA证书，因此客户端jvm需要对此证书进行导入（将证书添加到jvm信任的证书库）。线上环境由于是CA证书，因此client端无需进行证书导入

2.出于安全原因，server端会对cookie及webflow标识进行加密及签名，如果没有设置密钥（详见/WEB-INFO/cas.properties中tgc.encryption.key、tgc.signing.key、webflow.encryption.key、webflow.signing.key），服务启动时会产生警告信息并自动生成随机密钥（不会报错），此时需要将此密钥复制并保存到/WEB-INFO/cas.propertie相应字段，否则多个服务实例间将由于使用不同的密钥（各自生成随机密钥）导致各种解密失败，导致cookie及webflow在多实例间不可共享