cas客户端集成方案

Posted 2023-05-05

参考技术A

需要集成单点登录功能的第三方软件供应商

https://github.com/apereo/cas

http://www.ibm.com/developerworks/cn/opensource/os-cn-cas/index.html

https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol-Specification.html

CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。CAS 具有以下特点：

详细协议参考： https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol-Specification.html

1访问应用app1

用户访问 http://127.0.0.1/app1 ，
此时APP1通过检测session发现用户并没有登录于是重定向到cas-server。

注意：第三方集成需要实现此逻辑

2APP1重定向到cas-server请求登录认证

重定向地址 http://192.168.1.100/cas/login?service=http://127.0.0.1/app1/cas
附带一个service参数告诉cas-server认证成功后再次重定向的地址。

3用户输入用户名密码提交

4认证成功，返回ticket

cas-server接受客户的参数认证成功，并生成一个ticket，重定向给app1，重定向地址
http://127.0.0.1/app1/cas?ticket=XXXXXXX

5校验ticket

对于Java应用来说 http://127.0.0.1/app1/cas 看起来就是个Servlet或者filter，当这个filter接受到第四步的ticket后，立刻拿着这个ticket去cas-server验证用户认证信息。cas2.0协议中，验证这个ticket的地址为
http://192.168.1.100/cas/serviceValidate ，可以使用httpclient或者提供的客户端去调这个接口。

成功会返回

失败返回

注意：第三方集成需要根据协议流程图实现此filter或者servlet

6返回app1

由于APP1单点信任cas-server，在得到第5步的user信息后，将user信息存入app1的session，或者其他方式标识该用户认证成功。
至此用户登录完成，整个过程app1无法知晓用户的密码，用户名密码由cas-server统一管理。

1访问应用app2 http://127.0.0.1/app2

此时APP2通过检测session发现用户并没有登录于是重定向到cas-server

2APP1重定向到cas-server请求登录认证

重定向地址 http://192.168.1.100/cas/login?service=http://127.0.0.1/app1/cas
附带一个service参数告诉cas-server认证成功后重定向的地址。

3判断用户已经登录

cas检测session发现用户已经登录过，于是直接跳转到第四步 http://127.0.0.1/app2/cas?ticket=XXXXXXX
，而不是跳转到登录地址，这个过程对用户无感知。

4认证成功返回ticket

5校验ticket

于首次登录流程一致。

6返回app2

在用户这端访问APP2，直接就跳转到了登录后的页面，达到了免输用户名密码的效果，实际上在cas-server做了两次重定向。

参数

举例

https://cas.example.org/cas/login?service=http%3A%2F%2Fwww.example.org%2Fservice

调用这个接口，整个单点登录会话结束，其他应用单点登录功能失效。

举例

https://cas.example.org/cas/loout

参数

返回

失败

举例

https://cas.example.org/cas/validate?service=http%3A%2F%2Fwww.example.org%2Fservice&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7

CAS集成源码解析

CAS是其中一种SSO（单点登录）的实现，可以用做企业单点登录系统的集成。

CAS主要分为两个部分cas-server和cas-client，分别是集成在服务端（中央票据校验）和客户端（集成应用的子系统）。在应用改造层面，要先了解cas-server和cas-client的主要类和基本实现构架。

 

先从cas-client说起，cas-client主要要做的集成工作就是引入cas客户端的依赖，然后在web.xml中配置过滤器，过滤器会根据url来对来到cas-client的请求进行处理（转发或者直接进入系统）。对于cas-client的代码改造工作也大部分会在这几个过滤器中完成，在里面加入自己的业务需求。

web.xml有四个比较关键的过滤器：SingleSignOutFilter，CasAuthenticationFilter，Cas20ProxyReceivingTicketValidationFilter（cas20指的是用cas2.0协议，不同版本的cas这个类会不同），HttpServletRequestWrapperFilter；

1. SingleSignOutFilter 这个类放在第一个，判断url是否为登出请求，会做出一些清除票据信息和登录信息的操作；（为什么这个类要放在第一个？个人理解：如果是登出请求，后面的过滤器几乎完全没有必要走了，必须转发到cas服务器中做出申请票据什么的）；

2. CasAuthenticationFilter 这个类根据assertion是否为空来判断是否重定向至cas服务器进行登录验证（可以根据自己系统的需求增加不进行拦截的url（例如放行同步，级联，pki登录等流程））；

3. Cas20ProxyReceivingTicketValidationFilter 负责对Service Ticket的校验工作 底层通过HttpsURLConnection来完成后台校验Service Ticket 然后将获得的assertion放在会话中，方便子系统的下次跳转；

4. HttpServletRequestWrapperFilter 这个类是一个包装类，个人理解的不深入，有一个目的是允许通过HttpServletRequest的getRemoteUser()方法获得SSO登录用户的登录名，这个东西可以为以后的业务处理提供十分多的便利；

知道了这些入口流程类的话，一步一步往下看就比较容易了，细节之处就不深入分析了，在代码中还是比较容易理解的；

然后看看cas-server的主要骨架，cas-server中我觉得最关键的地方是用了spring-mvc的web-flow，当请求url进来spring webflow之后，定义了每一步的流程，跟着这个webflow一步步看下去，cas-server的大致流程就很好理解了。Spring-webflow有以下的关键类：

1. AuthenticationViaFormAction 验证登录方式（用户名密码）然后生成ticketGrantingTicket(tgt 这个东西是整个单点登录中最关键的)放在flow scope和Request scope中；（这两个scope是spring mvc里面的概念）

2. SendTicketGrantingTicketAction 将tgt放进浏览器的Cookie中

3. GenerateServiceTicketAction 验证tgt的有效性 根据tgt和service（cas-client子系统）生成Service Ticket

掌握了这些cas的至关重要的入口类之后，继续深入研究cas也会变得更加容易了。

由于直接这么描述源码会比较抽象，对cas的用法也难以理解，会另开一文来总结一下cas的大致流程。