Java学习爆破专栏“杀青”丨千锋一一哥Spring Security系列教程总结来咯！

Posted 2021-11-03 指尖上的代码go

　　内容回顾

　　截止到本篇文章，一一哥就带各位详细地学完了SpringSecurity中的各个核心内容，并结合源码带大家研读了SpringSecurity的底层设计。如果你认真地看完了我这个系列的每一篇文章，并跟着每篇教程中的代码编写了对应的案例，现在应该就可以达到从一开始对SpringSecurity的懵懂无知，到今天的熟练使用了。

　　最后 壹哥 再把整个系列的内容给各位梳理一下，方便各位复习掌握，我在这里做了一个SpringSecurity核心内容的思维导图，咱们一起看看吧。

 

 

　　1. SpringSecurity简介

　　通过本小节，我们了解到了SpringSecurity的基本概念、作用，以及与经典框架Shiro的区别，从中我们知道了SpringSecurity与Shiro的核心都是负责认证与授权，并且大家要知道认证与授权的含义及区别。

　　2. 初识SpringSecurity

　　然后我们通过一个案例，学习了如何在SpringBoot环境中利用SpringSecurity保护项目安全，并且了解到了SpringSecurity的基本使用。

　　3. 3种认证方式

　　SpringSecurity提供了3种安全认证方式，即基本认证、表单认证、摘要认证，其中表单认证用的比较多，请各位掌握表单认证的基本用法及底层原理。

　　因为目前开发基本都遵循前后端分离的开发模式，所以我们现在必须掌握前后端分离时的认证处理方案，主要是基于JSON进行认证信息的传递，包括认证成功、认证失败时的处理策略。

　　4. 2种授权方案

　　我们知道，SpringSecurity的核心功能包括认证和授权，其中授权的实现方案有2种，即基于内存模式的授权实现方案与基于数据库模式的授权实现方案，我们开发时主要是基于数据库模式来实现授权，这一章节也是我们必须重点掌握的内容。

　　5. SpringSecurity核心源码分析

　　我们开发时除了掌握必须的使用方法之外，还应该掌握SpringSecurity的核心源码，对SpringSecurity的底层认证、授权等流程原理有清晰的认识，做到知其然，还要知其所以然。

　　6. 实现图形验证码

　　在掌握了基本的认证授权基础之上，我们就可以进行一定程度的自定义开发，通过本章节就可以实现添加自定义的登录图形验证码，这里我们可以学习到2种添加验证码的方式，基于自定义过滤器和基于认证提供器来实现。

　　7. 实现自动登录与注销登录

　　利用SpringSecurity也可以很容易的实现自动登录与注销登录，另外我们还要掌握自动登录的实现原理。

　　8. 会话管理

　　通过本章节，我们主要是学习了会话的概念、HTTP协议、会话存在的问题，还有就是针对会话的各种攻击方式及拦截手段。另外本章节中，最重要的是掌握针对会话过期的处理策略，掌握会话并发处理方案和实现集群会话。

　　9. 密码加密方案

　　本章节中，我们主要是掌握SpringSecurity中提供的各种密码加密实现方案，以及密码加密的底层实现原理。

　　10. 4种权限控制方式

　　在本章节中，我给大家介绍了4种权限控制方式，常用的基于注解和Ant表达式的权限控制方式，这个章节也是我们必须要牢牢掌握的。

　　11. 跨域问题的解决

　　跨域问题是我们在前后端分离时经常会遇到的问题，对于什么是跨域，以及如何解决跨域问题，在本章节中都有详细介绍，我们主要是掌握SpringSecurity环境下的跨域问题解决方案。

　　12. 实现单点登录

　　因为目前分布式开发日渐普及，虽然带来了性能的提升，但是也带来了很多问题，比如常规的登录在分布式环境下就存在一定的问题，所以你可以通过本章节掌握到什么是单点登录，以及如何实现签名、如何基于SpringSecurity实现单点登录。

　　13. OAuth2.0协议简介

　　本章节主要是给大家介绍了另一个开源协议，即OAuth2.0协议，主要是掌握OAuth2.0协议中的认证授权方式及原理，这可以为我们后面学习OAuth2.0协议打下基础。

　　只要各位认真的阅读本系列教程中的内容，我相信你一定可以做到从入门到精通，后面我会推出一个利用SpringSecurity搭建的权限控制项目教程，希望各位长期关注 一一哥 哦。

　　专栏往期精彩内容

　　Spring Security开发专栏24章即将上线!

　　Spring Security开发正式上线!

　　Spring Security系列教程之创建项目

　　Spring Security系列教程之实现HTTP基本认证

　　Spring Security系列教程之实现Form表单认证

　　Spring Security系列之实现HTTP摘要认证

　　Spring Security系列之前后端分离时的安全处理方案

　　Spring Security系列教程之基于内存模型实现授权

　　Spring Security系列教程之基于默认数据库模型实现授权

　　Spring Security系列教之基于自定义数据库模型实现授权

　　spring security系列教程之Spring Security核心API讲解

　　Spring Security系列教程之Spring Security认证授权流程

　　Spring Security系列教程之基于过滤器实现图形验证码

　　Spring Security系列教程之基于自定义的认证提供器实现图形验证码

　　Spring Security系列教程之基于散列加密方案实现自动登录

　　Spring Security系列教程之注销登录的实现及原理分析

　　Spring Security系列教程之会话管理之防御固定会话攻击

　　Spring Security系列教程之会话管理之处理会话过期

　　Spring Security系列教程之会话管理之会话并发控制

　　Spring Security系列教程之会话管理之实现集群会话

　　Spring Security系列教程之SpringSecurity中的密码加密

　　Spring Security系列教程之Spring Security的四种权限控制方式

　　Spring Security系列教程之解决Spring Security环境中的跨域问题

　　Spring Security系列教程之基于持久化令牌方案实现自动登录

　　Spring Security系列教程之解决Spring Security环境中的跨域问题

　　Spring Security系列教程之实现CAS单点登录上篇-概述

　　Spring Security系列教程之实现CAS单点登录-搭建CAS服务端

　　Spring Security系列教程之实现CAS单点登录下篇-搭建CAS客户端

　　Spring Security系列教程之OAuth2.0协议详解

 

爆破专栏丨Spring Security系列教程之实现CAS单点登录上篇-概述

作者：千锋一一哥

前言

从本章节开始，一一哥 会给各位讲解一个很常见也很重要的知识点，就是单点登录！现在的大型分布式项目，基本都会考虑实现单点登录，而且现在网上也有很多单点登录的实现方案、开源项目，但是针对单点登录的实现原理，讲解的并不是很细。你可以参考其他开源案例项目，再结合本系列文章，就可以对单点登录有较为深入的认识。

如果你对单点登录是什么也不知道，那就先看本文，了解单点登录的含义吧。

一. 单点登录

1.产生背景

很早的时候，一家公司里可能只有一个Server，后来慢慢的Server开始变多了，而每个Server都要进行注册登录，退出的时候又要一个个退出，用户体验很不好！

比如，我们想访问百度系列，要登录百度知道、百度新闻、百度贴吧、百度图册…百度旗下的每一个产品，我们都分别注册一次账号，都分别登陆一次，都分别退出登录，这样一个一个Server去操作，可能会让人抓狂。

那么有没有办法，优化这样的登录体验呢？比如：一个公司名下的任意服务只需一次注册，登录的时候只要一次登录，退出的时候只要一次退出。如果可以实现这样的需求，用户体验是不是会有很大的提升？那么该用什么实现呢？

2.多系统中的登录实现方案

想在多系统项目中实现登录，目前有2种可行的实现方案：

• 同域名下共享Cookie
• 单点登录

3. 共享Cookie方案的缺陷

虽然同域名下共享Cookie的方式，可以在一定程度上解决多系统中的登录问题，但是该方案存在众多局限性，如下：

• 应用的群域名必须统一；
• 应用群中各系统使用的Web技术(至少是Web服务器)要相同，否则cookie中key的名称(Tomcat为JSESSIONID)不同，无法维持会话；
• 共享Cookie的方式无法实现跨语言技术平台登录，比如无法在Java、PHP、.Net等之间共享Cookie； Cookie本身也不安全。

4. SSO的概念

单点登录(Single Sign On)，简称为SSO，是目前比较流行的企业业务整合的解决方案之一。SSO是指在多应用系统中，用户只需要在某一个应用上登录一次，就可以同时在所有相关又彼此独立的系统中共享登录态。

即只登录一次，就能访问所有相互信任的应用系统，在其他所有系统中也都得到了授权而无需再次登录。另外用户也只需要退出一次，即可退出所有其他可信的服务。所以SSO包括单点登录与单点注销两部分。

5. SSO的优点

单点登录降低了用户的登录成本；
统一了不同系统之间的账号体系；
减少了各个系统在用户设计上付出的精力。

6. 使用场景

一般每个单独的系统都会有自己的安全体系和身份认证系统。在整合以前，进入每个系统都需要进行登录，这样的局面不仅给管理上带来了很大的困难，在安全方面也埋下了重大的隐患。下面是一些著名的调查公司显示的统计数据：

用户每天平均要花 16 分钟在身份验证任务上 - 资料来源： IDS
频繁的 IT 用户平均有 21 个密码 - 资料来源： NTA Monitor Password Survey
49% 的人写下了其密码，而 67% 的人很少改变它们
每 79 秒出现一起身份被窃事件 - 资料来源：National Small Business Travel Assoc
全球欺骗损失每年约 12B - 资料来源：Comm Fraud Control Assoc
在使用“单点登录”整合后，只需要登录一次就可以进入多个系统，而不需要重新登录。这不仅仅带来了更好的用户体验，更重要的是降低了安全的风险和管理的消耗。请看下面的统计数据：

提高 IT 效率：对于每 1000 个受管用户，每用户可节省$70K；
帮助台呼叫减少至少1/3，对于 10K 员工的公司，每年可以节省每用户 $75，或者合计 $648K；
生产力提高：每个新员工可节省 $1K，每个老员工可节省 $350 资料来源：Giga；
ROI 回报：7.5 到 13 个月 资料来源：Gartner
另外，使用 “单点登录” 还是SOA微服务时代的需求之一。在面向服务的架构中，服务和服务之间，程序和程序之间的通讯大量存在，服务之间的安全认证是SOA应用的难点之一。

应此建立“单点登录”的系统体系能够大大简化SOA的安全问题，提高服务之间的合作效率。

7. 单点登录执行流程(重点)

在单点登录系统中，需要定义一个独立的认证中心，只有认证中心才能接受用户的用户名密码等安全信息，而其他系统并不提供登录入口，只接受认证中心的间接授权，间接授权通过令牌实现。

SSO认证中心验证用户的用户名密码时如果没有问题，则创建授权令牌。在接下来的跳转过程中，授权令牌会作为参数发送给各个子系统，子系统拿到授权令牌，即得到了授权，可以借此创建局部会话，局部会话的登录方式与单系统的登录方式相同。

这个过程，就是单点登录的原理，我们用下图来详细说明。

根据上图，我们可以梳理出单点登录的请求执行流程(重点)：

比如用户访问系统1的受保护资源，结果系统1发现用户未登录，会先跳转到SSO认证中心，并将自己的地址作为参数，比如http://login.xxx.com/jump?target=http://系统1.com/xxx ；
SSO认证中心发现用户未登录，则将用户引导到登录页面，并将系统1的地址作为参数带过去；
用户输入用户名和密码，向SSO认证中心提交登录申请，并将系统1的地址作为参数带过去；
SSO认证中心校验用户信息，校验成功后，会创建一个用户与SSO认证中心之间的会话，称之为全局会话，同时创建一个授权令牌；
SSO认证中心带着令牌跳转回最初的请求地址(系统1)；
系统1拿到授权令牌后，接着去SSO认证中心校验令牌是否有效，并将系统1的地址作为参数带过去；
SSO认证中心先校验令牌是否有效，正常则返回有效信息，并把系统1的信息注册进SSO授权中心；
系统1使用该授权令牌创建出与用户的会话，称为局部会话，然后给用户返回受保护的资源；
如果用户继续访问系统2的受保护资源，也会与SSO授权中心进行交互授权；
比如系统2发现用户未登录，则跳转到SSO认证中心，并将自己的地址作为参数携带过去；
如果SSO认证中心发现用户已登录，则跳转回系统2的地址，并带过去授权令牌；
系统2拿到授权令牌，接着会去SSO认证中心校验授权令牌是否有效；
SSO认证中心也会校验授权令牌，并返回有效信息，把系统2的信息也注册进行SSO授权中心；
系统2使用该授权令牌创建一个与用户的局部会话，返并回受保护的资源。
通过以上的SSO单点登录执行流程，我们可以得知，用户登录成功之后，会与SSO认证中心及各个子系统之间建立会话。

用户与SSO认证中心建立的会话称为全局会话，用户与各个子系统建立的会话称为局部会话，局部会话建立之后，用户访问子系统受保护资源将不再通过SSO认证中心。全局会话与局部会话有如下约束关系：

局部会话存在，全局会话一定存在；
全局会话存在，局部会话不一定存在；
全局会话销毁，局部会话必须销毁。
单点登录涉及到SSO认证中心与众多子系统，各子系统与SSO认证中心之间需要通信以交换令牌、校验令牌及发起注销请求，因而各子系统必须集成SSO客户端，SSO认证中心则是SSO服务端，整个单点登录过程实质是SSO客户端与服务端通信的过程。

8. 单独注销执行流程(重点)

在多应用系统中，我们既然实现了单点登录，自然也要单点注销，即在一个子系统中注销后，所有子系统的会话都将被销毁。我们用下图来说明。

SSO认证中心会一直监听全局会话的状态，一旦发现全局会话被销毁，监听器将通知所有注册系统执行注销操作。

下面对上图进行简要说明：

比如用户向系统1发起注销请求；
系统1根据用户与系统1建立的局部会话id拿到授权令牌，接着系统1向SSO认证中心发起注销请求；
SSO认证中心会先校验授权令牌是否有效，然后销毁全局会话，同时取出所有用此授权令牌注册的系统地址；
SSO认证中心向所有注册系统发起注销会话的请求；
各注册系统接收到SSO认证中心的注销请求，销毁局部会话；
最后SSO认证中心会引导用户到登录页面。

二. CAS单点登录系统

1. CAS概念

前文我们给大家介绍过，如果在一个企业旗下的所有系统都使用同一域名，其实实现单点登录也挺简单，我们只需要将Cookie的domain域设置为顶层域名，在服务器端进行会话共享即可。但是现实中并没有这么理想的状态，一般实现单点登录的成本是比较高的，接下来我给大家介绍一个实现单点登录的开源项目CAS，可以大大降低实现单点登录的难度和开发成本。

CAS(Central Authentication Service)，即中心认证服务系统。在CAS系统中，分为CAS Server与CAS Client两部分，CAS Server是单点登录系统中负责验证的服务端，CAS Client是CAS Server登录态的客户端。

2. CAS的核心概念(重点)

在CAS系统中有三个重要的术语：

Ticket Grantfng Ticke(TGT)：这是用户登录后生成的票根，包含用户的认证身份、有效期等信息，存储于CAS Server中，类似于我们常见的服务器会话；
Ticket Granted Cookie(TGC)：这是存储在Cookie中的一段数据，类似于会话ID，用户与CAS Server进行交互时，帮助用户找到对应的TGT；
Service Ticket(ST)：这是CAS Server使用TGT签发的一张一次性票据，CAS Client 使用ST与CAS Server进行交互，以获取用户的验证状态。

3. CAS单点登录执行步骤(重点)

CAS单点登录的完整步骤如下：

（1）用户先通过浏览器访问CAS Client程序的某个页面，例如http://cas.client.com/me；

（2）当CAS Client判断用户需要进行身份认证时，会携带service作为请求参数，并返回302状态码，指示浏览器重定向到CAS Server端，例如 http://cas.server.com/?service=http://cas. client.com/me.service，service是用户的原访问页面；

（3）然后浏览器利用 service 重定向到CAS Server；

（4）CAS Server 获取并校验用户cookie中携带的TGC，如果成功，则身份认证完成；否则将用户重定向到CAS Server 提供的登录页，例如 http://cas.server.com/login?service=http://cas. client.com/me，由用户输入用户名和密码，完成身份认证；

（5）如果用户已经登录过系统，那么CAS Server可以直接获取用户的TGC，并根据TGC找到TGT。如果是首次登录，则CAS Server 会首先生成TGT。每次验证时，CAS Server 会根据 TGT签发一个ST，并把ST拼接在service参数中，同时将相应的TGC设置到用户的cookie中(域为CAS Server)，并返回302 状态码，指示浏览器重定向到 service，例如 http://cas.client.com/me?ticket=XXX；

（6）浏览器存储TGC，并携带ST重定向到service；

（7）CAS Client取得ST(即请求参数中的ticket)后，会向CAS Server请求验证该ST的有效性；

（8）若CAS Server验证该ST是有效的，就告知CAS Client该用户有效，并返回该用户的信息。

CAS Client在获取用户信息时，可以使用session的形式管理用户会话。后续的交互请求不再需要重定向到CAS Server，CAS Client直接返回用户请求的资源即可，整个流程如下图所示：

请各位把上面的单点登录执行流程和CAS的核心概念牢固掌握，这些知识点有助于我们后文知识点的理解和掌握。敬请期待下文，如何搭建CAS服务端！

本文来自千锋教育，转载请注明出处。