单点登录与权限管理-SSO

源码练习下载：https://gitee.com/ctocloud/spring-boot-sso.git
源码练习下载：https://gitee.com/ctocloud/simple-sso.git

一、「单点登录与权限管理」系列概述

结合实际项目，写写netty系列，但后面一个月工作会比较忙，就决定写写和后面工作关联度大的技术，一边调研、实践，一边整理、分享给大家。

该系列主要以我们系统「单点登录与权限管理」的实现为主线，深入了解下CAS、Shiro，扩展了解下OAuth、Spring Security、Spring Session，计划内容如下：

单点登录与权限管理本质
项目背景介绍
项目基本实现
由浅入深了解CAS
由浅入深了解Shiro
CAS和Shiro改造过程
了解和尝试OAuth
了解和尝试Spring Security
了解和尝试Spring Session

其实，列出的这些技术点，我也没有深入了解过，但会尽力分享学习、实践的过程，大家多支持和包容。

二、单点登录与权限管理本质：session和cookie介绍

文章介绍下session和cookie，它是登录实现的基础，主要从下面几个方面介绍：

session和cookie基本概念
session的生命周期
cookie的作用域

cookie的跨域问题会在后续文章单独介绍。

基本概念

大部分系统都需要识别用户的身份，有些功能只有特定的用户能使用，有些功能需要根据用户身份显示不同的内容，一般使用唯一编号标识用户的身份。

就像我们的身份证，身份证号是每个人唯一的，根据所在的省市区、出生年月、性别等规则生成，我们去政府机构办事时，都需要带着身份证，他们通过身份证验证我们的身份。

session和cookie主要用来识别登录者身份的，默认通过JSESSIONID唯一编号进行验证。session是在服务端保存的一个数据结构，用来跟踪用户的状态，也可以保存用户相关的一些数据，可以保存在内存、缓存、数据库等存储结构中。cookie是客户端保存用户信息的一种机制。

servlet session

javax.servlet.http包中是session的主要API接口，主要有以下几种接口：

HttpSession：实际的session接口定义；
Listener：session发生一些动作，如创建，设置属性，失效等，会触发一些事件，进行相应的处理；
Event：当动作触发之后，封装为对应的事件；

Session相关接口：

session相关的接口，一般由应用服务器来实现，比如Tomcat、Resin、Jetty。Session的主要特征：

可以设置和获取一些属性；
每个session对应一个编号sessionId，是一次会话的唯一表示；
session有超时时间，用户长时间无操作，维护的定时器会清除session，保证资源及时释放；
可以通过调用invalidate方法主动清除session；

在tomcat中，HttpSession的实现是StandardSession，同时StandardSession会实现自定义的Session接口，它是对HttpSesion一个包装。

TomcatSession接口：

另外，tomcat会实现session的管理和持久化，可随时获取到对应的session，具体实现不在本篇分析，网上有很多文章介绍。

cookie

cookie是客户端的解决方案，是服务器发给客户端的特殊信息，这些信息以文本文件的方式存放在客户端，后续请求，客户端都会带上这些特殊的信息。

服务端通过HTTPResponse设置cookie到响应头，发送到客户端，后续客户端自动将cookie信息设置到请求头。下面是我登录百度后的cookie信息：

cookie也有失效时间，可在服务端通过cookie.setMaxAge(expiry)进行设置，expiry=-1：代表浏览器关闭后，cookie就失效了；expiry>0：代表会将cookie保存到硬盘中，直到设置时间过期才会被浏览器自动删除；expiry=0：删除cookie，cookie都会被浏览器给删除。

另外还有其他几个特性：

setDomain：设置cookie范围，后面会详细介绍；
isHttpOnly：是否只是http协议使用。只能在后端通过getCookies()获取，js不能获取；
每一个cookie文件大小：4kb ，如果超过4kb浏览器不识别；
cookie不安全，可能泄露用户信息，浏览器支持禁用cookie操作；
临时session：默认生命周期，当浏览器关闭时cookie销毁的；

交互过程

使用浏览器访问服务端页面；
服务端收到该客户端第一次请求后，会创建一个session，生产一个唯一sessionId；
同时在响应请求中设置cookie，属性名为jessionid；
客户端收到后会保存jessionid，再次请求时，会在header中设置，服务端可从请求头中获取；
服务端验证获取的sessionId是否存在，即可验证是否是同一用户；

当浏览器禁用cookie后，基于cookie的session将不能正常工作，每次都将创建一个新的session，可通过url重写传递jsessionid。

session的生命周期

session存储在服务器端，session在用户第一次访问时创建，访问jsp、servlet等程序时才会创建Session，只访问html、image等静态资源并不会创建，可调用request.getSession(true)强制生成Session。

服务器会把长时间没有活动的Session从内存中清除，tomcat中session的默认失效时间为20分钟，可调用调用session的invalidate方法强制清楚。

另外，我们可以自己实现session生命周期的管理，以满足特定的业务需求，比如后续要讲的单点登录、分布式session等，tomcat可提供了相应扩展，后续文章会介绍。

cookie的作用域

创建cookie时，需要设置domain，有多级域名时，可以控制cookie的作用域。如果网站请求量很大，设置的cookie作用域不当，会浪费很多流量。

下面举例说明，比如有三级域名support.kefu.mi.com，其中，mi.com是一级域名，kefu.mi.com是二级域名。

在3类域名下进行cookie设置，分别设置不同的domain，看看访问各级域名时cookie的有效性。当domain设置为空时，domain默认为当前域名。

在一级域名mi.com下设置cookie

domain参数	访问一级	访问二级	访问三级
空	√	√	√
mi.com	√	√	√
kefu.mi.com	×	×	×
mcc.kefu.mi.com	×	×	×

当domain为一级域名时，一级域名、包括其下的子域名都可以接收到cookie。但是domain参数设置其子域名时，所有域名就接收不到了，包括那个子域名。

在二级域名kefu.mi.com下设置cookie

domain参数	访问一级	访问二级	访问三级
空	×	√	√
mi.com	√	√	√
kefu.mi.com	×	√	√
mcc.kefu.mi.com	×	×	×

当domain为自身域名时，其父域名无法接收到cookie，其本身与其子域名可以接收到cookie。而设置其子域名或其他域名时，所有域名都接收不到cookie。

在三级域名mcc.kefu.mi.com下设置cookie

domain参数	访问一级	访问二级	访问三级
空	×	×	√
mi.com	√	√	√
kefu.mi.com	×	√	√
mcc.kefu.mi.com	×	×	√

可以得出结论：domain参数可以设置父域名以及自身，但不能设置其它域名，包括子域名，否则cookie不起作用。

三、单点登录与权限管理本质：HTTP重定向

HTTP重定向，它也是完成单点登录的基础知识。

单点登录需要在多个web项目之间相互跳转，使用重定向技术，自动完成登录操作。另外，当实际资源被迁移到其他URL时，可使用重定向技术，将访问原有URL的请求，自动跳转到新URL，保持原有URL有效。

本篇主要从以下几个方面介绍：

重定向基本概念
Nginx重定向
Servlet重定向
Spring使用重定向

一、基本概念

基本原理

在HTTP协议中，服务器通过发送特定的响应实现重定向，浏览器在接收到响应后，可根据状态码判定重定向，并使用指定的新URL重新请求。重定向的响应状态码为3xx，不同的状态码表示不同的重定向类型。

重定向基本原理

浏览器从响应头中的Location获取新的URL，重新发送请求。

重定向类型

重定向类型包括永久重定向、临时重定向、特殊重定向，不同的重定向类型，一方面会影响浏览器的操作，一方面会影响搜索引擎的收录。

永久重定向，是指原URL不再被使用，应优先选择新的URL，搜索引擎机器人会在遇到该状态码时，触发更新操作，使用新的URL。常见的状态码有301，Moved Permanently。

临时重定向，如果请求的资源临时不可用，但可从其他地方访问。搜索引擎不会记录该临时的链接。常见的状态码有302 Found，307 Temporary Redirect。

特殊重定向，304 Not Modified 资源未被修改，会从本地缓存中获取网页；300 Multiple Choice，是一种手工重定向，用户可选择重定向的页面。

设置重定向方法

除了上面介绍的重定向方法，还可以通过HTML的metay元素，或者JS实现重定向，但还是建议优先选择上面介绍方法。

<head> 
  <meta http-equiv="refresh" content="0;URL=https://www.mi.com" />
</head>

content属性值，第一个数字表示等待多少秒后进行跳转。

window.location = "https://www.mi.com";

二、Nginx重定向

rewrite

nginx的rewrite主要功能就是实现URL的重定向，其语法规则如下：

rewrite <regex> <replacement> [flag]

regex 正则匹配需要重定向的url
replacement 替换内容，将正则匹配的内容替换成replacement
flag 标记，具体如下：

last：本条规则匹配之后，继续向下匹配新的rewrite；
break：本条规则匹配完成即终止，后面的规则不再匹配；
redirect：返回302临时重定向；
permanent：返回301永久重定向；

rewirte参数的标签段位置：server,location,if

rewrite示例

将 mi.com 重定向 www.mi.com

server {
        listen 80;
        server_name mi.com;
        rewrite ^/(.*) http://www.mi.com/$1 permanent;
}

return

可通过return直接重定向，如下：

server {
    listen 80;
    server_name example.com;
    return 301 $scheme://www.mi.com$request_uri;
}

三、Servlet重定向

首先要区分开转发和重定向的概念，转发是在服务端完成的，浏览器地址栏中的地址不会改变，是一次请求；重定向是在浏览器端完成的，浏览器地址栏会变化，是二次请求。

无论是转发还是重定向，在执行方法前，不要向客户端输出内容.

public void doPost(HttpServletRequest request,HttpServletResponse response) throws ServletException,IOException { 
    response.setContentType("text/html; charset=utf-8"); 
    ServletContext sc = getServletContext();    
    RequestDispatcher dispatcher = null; 
    dispatcher = sc.getRequestDispatcher("index.jsp");              
    dispatcher.forward(request, response); 
}

重定向

public void doPost(HttpServletRequest request,HttpServletResponse response) throws ServletException,IOException { 
    response.setContentType("text/html; charset=utf-8"); 
    response.sendRedirect("/index.jsp"); 
}

四、Spring使用重定向

不带参数

return new ModelAndView("redirect:/toList");

return "redirect:/toList";

带参数

public String test(RedirectAttributes attributes) 
{ 
    attributes.addAttribute("hello", "hello"); 
    return "redirect:/toList"; 
}

这样会在重定向后的url中自动追加参数。

Spring MVC 3.1 版本添加了一个新特性，Flash属性，可以实现传递参数，并且可以解决重复提交的问题。

一个正常的Controller处理时，处理完成之后，会被forward到一个操作成功的页面，如果用户按F5，就会再次提交一遍，如果使用redirect，就可以避免这个问题。

public String test(RedirectAttributes attributes)  {  
    attributes.addFlashAttribute("hello", "hello");
    return "redirect:/toList";  
}

四、单点登录与权限管理本质：单点登录介绍

单点登录，所谓单点登录，就是说用户只需在一个地方登录，访问其他相关系统时，不需要重复登录，隐式地自动登录，这样体验会比较好。

主要从以下几个方面介绍：

一个常见的交互流程
常见单点登录协议
关键问题总结

一个常见的交互流程

我们项目中，使用CAS协议实现单点登录，下面就以项目中的实现为例，先来看下其交互流程，对其实现有个基本的了解。

有2个系统，系统A是「客服工作台」，主要给客服使用，可实时与来访用户及时聊天，解答用户的问题。系统B是「工单系统」，对于不能解答的问题，客服会创建一个工单，更高级别或相关度高的人会看到工单进行处理。

客服希望在登录系统A后，不需要手动登录系统B，需要一个「单点登录服务」，提供一个统一的登录验证，协调系统A、系统B的自动登录，定义该服务为服务S，其CAS协议的场景的流程如下：

CAS协议交互图

花了不少时间画上面的图，看着比较复杂，其实还好，希望大家花时间看下，如果前两篇文章真正理解了，这块就相对简单了。

重点总结下该流程：

黑圆圈红字，标识cookie的生成和使用，ABCDE表示5个cookie，1表示生成，2表示使用；
无论是系统A，还是系统B，如果没有jessionid cookie，都会跳转到服务S，如果携带了cookie1（登录成功后生成的cookie），不需要登录，会自动登录，如果没有携带cookie1，会跳转到登录页面，登录成功后会设置cookie1。
cookie1是保持浏览器和服务S的，表示用户已经登录过了；
cookie2、cookie4都是临时cookie，主要是将服务码带到系统A或系统B，拿到服务码后，通过后端请求服务S进行验证，验证过后，临时cookie就失效了，主要是为了安全考虑。
cookie3、cookie5和我们正常登录产生的jessionid一样，是各个子系统独有的cookie；

常见单点登录协议

上面介绍的是CAS协议的一种，还有其他协议可实现单点登录，比如CAS官网列举的协议：

常见单点登录协议

这些协议有不同的适用场景，比如好多网站都支持使用QQ、微信、微博直接登录，只要你的QQ、微信、微博登录者，就不用重复登录，使用OAuth协议可比较好的实现这种场景。

后面会单独介绍这些协议。

关键问题总结

无论是哪一种协议，都需要一个中间系统，对验证和授权进行统一管理。

另外，cookie的管理和安全问题需要重点考虑。

介绍下可能存在哪些安全问题，而对于安全问题如何解决，cookie和session具体如何管理。