松哥手把手教你入门 Spring Boot + CAS 单点登陆

在微服务以及分布式系统中，单点登陆变得愈来愈广泛，松哥以前也有两篇文章和你们介绍过单点登陆的方案：

• OAuth2+JWT 方案
• @EnableOAuth2Sso 注解方案

这两种方案中，JWT 存在一个注销登陆的问题，要费点功夫解决。@EnableOAuth2Sso 注解这种方案不存在注销登陆的问题，可是又不像 JWT 那么灵活。

没有银弹！

在实际项目中，咱们只能根据本身的实际需求，看一看哪种方案更适合本身，而后在此基础上进行改造！

如今咱们在 Spring Cloud Security 中使用 OAuth2+JWT 或者使用 @EnableOAuth2Sso 注解比之前要方便不少了，松哥也是最近才把项目切换到 Spring Cloud Security 技术栈上面来，在这以前，单点登陆用的更多的是 CAS 单点登陆。相信有很多小伙伴在公司里可能也仍是使用了 CAS 单点登陆这种方案，今天松哥就来花点时间，和你们聊聊 CAS+Spring Security 实现单点登陆，这种方案到底该怎么玩。

可能会连续几篇文章来介绍 CAS 单点登陆，本文先来讲说理论和登陆流程。另外，因为 CAS 和 Spring Cloud OAuth2 在某些方面具备必定的类似性，因此强烈建议你们先看一看松哥的 OAuth2 系列教程，再来阅读本文就会轻松不少（公众号后台回复 OAuth2 有相关教程）。

本文是 Spring Security 系列第 23 篇，阅读本系列前面的文章有助于更好的理解本文：

1. 挖一个大坑，Spring Security 开搞！
2. 松哥手把手带你入门 Spring Security，别再问密码怎么解密了
3. 手把手教你定制 Spring Security 中的表单登陆
4. Spring Security 作先后端分离，咱就别作页面跳转了！通通 JSON 交互
5. Spring Security 中的受权操做原来这么简单
6. Spring Security 如何将用户数据存入数据库？
7. Spring Security+Spring Data Jpa 强强联手，安全管理只有更简单！
8. Spring Boot + Spring Security 实现自动登陆功能
9. Spring Boot 自动登陆，安全风险要怎么控制？
10. 在微服务项目中，Spring Security 比 Shiro 强在哪？
11. SpringSecurity 自定义认证逻辑的两种方式(高级玩法)
12. Spring Security 中如何快速查看登陆用户 IP 地址等信息？
13. Spring Security 自动踢掉前一个登陆用户，一个配置搞定！
14. Spring Boot + Vue 先后端分离项目，如何踢掉已登陆用户？
15. Spring Security 自带防火墙！你都不知道本身的系统有多安全！
16. 什么是会话固定攻击？Spring Boot 中要如何防护会话固定攻击？
17. 集群化部署，Spring Security 要如何处理 session 共享？
18. 松哥手把手教你在 SpringBoot 中防护 CSRF 攻击！so easy！
19. 要学就学透彻！Spring Security 中 CSRF 防护源码解析
20. Spring Boot 中密码加密的两种姿式！
21. Spring Security 要怎么学？为何必定要成体系的学习？
22. Spring Security 两种资源放行策略，千万别用错了！

1.什么是 CAS

CAS 全称叫作中央认证服务，英文是 Central Authentication Service。

这是由耶鲁大学发起的一个开源项目，目的是帮助 Web 应用系统构建一种可靠的单点登陆解决方案，从目前企业实际项目来看，CAS 仍是很是受欢迎的一种单点登陆解决方案。

1.1 CAS 架构

CAS 分为两部分：

• 一个是 CAS Server，这是单点验证服务，做用相似于咱们OAuth2+JWT 方案中的受权服务器，用来校验用户名/密码等，通常来讲都是独立部署。
• 另外一个则是 CAS Client，至关于就是一个一个的（微）服务。

咱们来看 CAS 的官方给出的一个架构图：

能够看到，用户访问的是 CAS Clients，CAS Clients 和 CAS Server 之间的通讯支持多种协议，CAS Server 处理具体的认证事宜，CAS Server 对数据源的支持也很是多样化。

CAS Client 支持的平台有：

• Apache httpd Server (mod_auth_cas module)
• Java (Java CAS Client)
• .NET (.NET CAS Client)
• PHP (phpCAS)
• Perl (PerlCAS)
• Python (pycas)
• Ruby (rubycas-client)

CAS 支持的通讯协议有：

• CAS (versions 1, 2, and 3)
• SAML 1.1 and 2
• OpenID Connect
• OpenID
• OAuth 2.0
• WS Federation

从图中也能够看出 CAS 支持多种不一样的认证机制，具体有：

• JAAS
• LDAP
• RDBMS
• SPNEGO
• ...

1.2 三个概念

在 CAS 的整个登陆过程当中，有三个重要的概念，这里我先来和你们捋一捋。

1. TGT：TGT 全称叫作 Ticket Granting Ticket，这个至关于咱们平时所见到的 HttpSession 的做用，用户登陆成功后，用户的基本信息，如用户名、登陆有效期等信息，都将存储在此。
2. TGC：TGC 全称叫作 Ticket Granting Cookie，TGC 以 Cookie 的形式保存在浏览器中，根据 TGC 能够帮助用户找到对应的 TGT，因此这个 TGC 有点相似与会话 ID。
3. ST：ST 全称是 Service Ticket，这是 CAS Sever 经过 TGT 给用户发放的一张票据，用户在访问其余服务时，发现没有 Cookie 或者 ST ，那么就会 302 到 CAS Server 获取 ST，而后会携带着 ST 302 回来，CAS Client 则经过 ST 去 CAS Server 上获取用户的登陆状态。

2.CAS 登陆流程

接下来咱们经过一张官方给出的流程图来看下 CAS 登陆过程是什么样子的！

这张图其实画的比较清楚了，我再用文字和你们解释下：

术语：应用一、应用2 分别表示被保护的应用。

1. 用户经过浏览器访问应用1，应用1 发现用户没有登陆，因而返回 302，而且携带上一个 service 参数，让用户去 CAS Server 上登陆。
2. 浏览器自动重定向到 CAS Server 上，CAS Server 获取用户 Cookie 中携带的 TGC，去校验用户是否已经登陆，若是已经登陆，则完成身份校验（此时 CAS Server 能够根据用户的 TGC 找到 TGT，进而获取用户的信息）；若是未登陆，则重定向到 CAS Server 的登陆页面，用户输入用户名/密码，CAS Server 会生成 TGT，而且根据 TGT 签发一个 ST，再将 TGC 放在用户的 Cookie 中，完成身份校验。
3. CAS Server 完成身份校验以后，会将 ST 拼接在 service 中，返回 302，浏览器将首先将 TGC 存在 Cookie 中，而后根据 302 的指示，携带上 ST 重定向到应用1。
4. 应用1 收到浏览器传来的 ST 以后，拿去 CAS Server 上校验，去判断用户的登陆状态，若是用户登陆合法，CAS Server 就会返回用户信息给 应用1。
5. 浏览器再去访问应用2，应用2 发现用户未登陆，重定向到 CAS Server。
6. CAS Server 发现此时用户实际上已经登陆了，因而又重定向回应用2，同时携带上 ST。
7. 应用2 拿着 ST 去 CAS Server 上校验，获取用户的登陆信息。

在整个登陆过程当中，浏览器分别和 CAS Server、应用一、应用2 创建了会话，其中，和 CAS Server 创建的会话称之为全局会话，和应用一、应用2 创建的会话称之为局部会话；一旦局部会话成功创建，之后用户再去访问应用一、应用2 就不会通过 CAS Server 了。

3.CAS Server 搭建

说了这么多，来点实际的。

因为整个 CAS 单点登陆作起来还比较麻烦，咱们一步一步来，今天我先来教你们把 CAS Server 搭建起来。

3.1 版本选择

目前最新的 CAS Server 是 6.x，这个是基于 gradle 来构建的，考虑到不少小伙伴可能不熟悉 gradle 操做，所以这里我选择 5.3 的版本，该版本基于你们熟悉的 maven 来构建。

官方为咱们提供了构建 CAS Server 的模版，地址是：https://github.com/apereo/cas...。

咱们在分支中选择 5.3 版本下载：

或者直接 clone 下来，而后切换到 5.3 这个分支也能够。这个应该就不用我教你们了吧，相信小伙伴们都能本身搞定。

3.2 HTTPS 证书

CAS Server 从版本 4 开始，要使用 HTTPS 通讯，因此咱们得提早准备 HTTPS 证书。公司里的项目的话，须要购买 HTTPS 证书，本身玩的话也能够从云服务厂商那里申请到免费的 HTTPS 证书。

如今咱们在本地测试，直接利用 JDK 自带的 keytool 工具，本身生成一个 HTTPS 证书便可。

生成命令以下：

keytool -genkey -alias casserver -keyalg RSA -keystore ./keystore

• -alias 表示生成的证书别名
• -keyalg 表示生成证书使用的算法
• -keystore 表示生成证书的存放位置

证书在执行的时候，须要给一个密钥库口令，这个你们随意给出便可，可是给出了多少要本身记着。另外，在 What is your first and last name? 选项中，须要填入 CAS Server 的域名，这点切记：

如此以后，咱们的 HTTPS 证书就有了，虽然这个证书不被各大厂商承认，可是本身作练习够用了。

3.3 配置并启动

接下来进行配置。

咱们在下载的 cas-overlay-template 项目中，新建 src/main/resources 目录，并将 overlays/org.apereo.cas.cas-server-webapp-tomcat-5.3.14/WEB-INF/classes/application.properties 文件和刚刚生成的 keystore 文件拷贝进来：

而后修改 application.properties ，主要配置一下 keystore 的位置和密钥，以下:

server.ssl.key-store=classpath:keystore
server.ssl.key-store-password=111111
server.ssl.key-password=111111

配置完成后，在项目根目录下执行以下命令启动项目：

./build.sh bootrun

根据我的网速，第一次启动可能会很是漫长，耐心等待便可。

启动过程当中，也可能会报错，可是不用管，若是看到 ready 图标，就表示启动成功了：

3.4 测试

启动成功后，浏览器输入 https://cas.javaboy.org:8443/cas/login 就能够进入登陆页面了（注意是 https 哦）：

默认的用户名是 casuser，密码是 Mellon，输入用户名密码就能够登陆了。

默认的用户名/密码也能够在 application.properties 文件中修改，该文件的最后一行：

cas.authn.accept.users=casuser::Mellon

修改完后，重启项目便可生效。

4.小结

今天主要和小伙伴聊一下 CAS 的基本概念，而后咱们顺手搭建一个 CAS Server 出来，感兴趣的小伙伴能够动手试一试哦～，下篇文章咱们来看如何用 Spring Boot 开发 CAS 客户端～

好啦，若是小伙伴们以为有收获，记得点个在看鼓励下松哥哦～