你还不了解基于session的授权认证吗？

前言

在漫长的开发过程中，权限认证是一个永恒不变的话题，随着技术的发展，从以前的基于sessionId的方式，变为如今的token方式。session常用于单体应用，后来由于微服务的兴起，分布式应用占了很大的一部分。本文将为大家介绍基于session的单体应用授权认证方式。后续会介绍基于token的认证方式。

什么是认证

输入账号和密码登录的过程就是认证，看是否合法。认证是为了保护系统的隐私数据和资源。用户的身份合法才能访问该系统资源。
用户认证就是判断一个用户身份是否合法的过程，合法继续访问，不合法拒绝访问。
常见的用户认证方式有：用户密码登录，手机短信登录，指纹认证等。

什么是会话

用户认证通过后，为了避免用户的每次操作都进行认证，可以将用户的信息保存在会话中，会话就是为了保持当前用户的登录状态，提供的一种机制。
常见的有基于session方式、基于token方式。

session方式会话

用户认证成功后，在服务端生成用户相关的数据保存在session中，发给客户端的session_id存放到cookie中。用户客户端请求的时候带上session_id就可以验证服务器是否存在session数据，以此完成用户的合法校验。当用户退出系统或session过期销毁，客户端的session_id也就无效了。

token方式会话

用户认证成功后，服务端生成一个token发给客户端，客户端放到cookie或localstorage等存储中。每次请求时，带上token，服务端收到token通过验证后，可以确认用户身份。

总结

基于session的认证方式由servlet规范定制，服务端要存储session信息需要占用内存资源，客户端需要支持cookie。基于token的方式一般不需要服务端存储token，并且不限制客户端的存储方式。如今互联网时代多客户端，所以token更合适。

什么是授权

比如微信，发红包功能，发朋友圈功能都是微信资源，用户有发红包的功能才能正常使用，比如一开始用户没有绑定银行卡，用户就没有发红包权限。
认证是为了保护用户身份的合法性，授权则是为了更细粒度的对隐私数据进行划分，授权是认证通过后发生的，控制不同的用户能够访问不同的资源。
授权是用户认证通过根据用户的权限来控制用户访问资源的过程，拥有资源的访问权限则正常访问，没有权限则拒绝访问。

授权的数据模型

授权可简单理解为Who对What(which)进行How操作，包括如下：
Who，即主体（Subject），主体一般是指用户，也可以是程序，需要访问系统中的资源。
What，即资源（Resource），如系统菜单、页面、按钮、代码方法、系统商品信息、系统订单信息等。系统菜单、页面、按钮、代码方法都属于系统功能资源，对于web系统每个功能资源通常对应一个URL；系统商品信息、系统订单信息都属于实体资源（数据资源），实体资源由资源类型和资源实例组成，比如商品信息为资源类型，商品编号为001的商品为资源实例。
How，权限/许可（Permission），规定了用户对资源的操作许可，权限离开资源没有意义，如用户查询权限、用户添加权限、某个代码方法的调用权限、编号为001的用户的修改权限等，通过权限可知用户对哪些资源都有哪些操作许可。
主体、资源、权限关系如下：

主体、资源、权限相关的数据模型如下：
主体（用户id、账号、密码、…）
资源（资源id、资源名称、访问地址、…）
权限（权限id、权限标识、权限名称、资源id、…）
角色（角色id、角色名称、…）
角色和权限关系（角色id、权限id、…）
主体（用户）和角色关系（用户id、角色id、…）
主体（用户）、资源、权限关系如下图：

通常企业开发中将资源和权限表合并为一张权限表，如下：
资源（资源id、资源名称、访问地址、…）
权限（权限id、权限标识、权限名称、资源id、…）
合并为：
权限（权限id、权限标识、权限名称、资源名称、资源访问地址、…）
修改后数据模型之间的关系如下图：

RBAC

基于角色的访问控制

RBAC基于角色的访问控制（Role-Based Access Control）是按角色进行授权，比如：主体的角色为总经理可以查询企业运营报表，查询员工工资信息等，访问控制流程如下：

根据上图中的判断逻辑，授权代码可表示如下：

如果上图中查询工资所需要的角色变化为总经理和部门经理，此时就需要修改判断逻辑为“判断用户的角色是否是总经理或部门经理”，修改代码如下：

根据上边的例子发现，当需要修改角色的权限时就需要修改授权的相关代码，系统可扩展性差。

基于资源的访问控制

RBAC基于资源的访问控制（Resource-Based Access Control）是按资源（或权限）进行授权，比如：用户必须具有查询工资权限才可以查询员工工资信息等，访问控制流程如下：

根据上图中的判断，授权代码可以表示为：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9nocXOcf-1592012273875)(https://img2020.cnblogs.com/blog/1534147/202005/1534147-20200521090816642-1313044338.png)]

优点：系统设计时定义好查询工资的权限标识，即使查询工资所需要的角色变化为总经理和部门经理也不需要修改授权代码，系统可扩展性强。

基于session的认证方式

基于Session认证方式的流程是，用户认证成功后，在服务端生成用户相关的数据保存在session(当前会话)，而发给客户端的 sesssion_id 存放到 cookie 中，这样用客户端请求时带上 session_id 就可以验证服务器端是否存在 session 数据，以此完成用户的合法校验。当用户退出系统或session过期销毁时,客户端的session_id也就无效了。
下图是session认证方式的流程图：

基于Session的认证机制由Servlet规范定制，Servlet容器已实现，用户通过HttpSession的操作方法即可实现，如下是HttpSession相关的操作API。

基于session的工程

本案例工程使用maven进行构建，使用SpringMVC、Servlet3.0实现。

创建maven工程

创建maven工程 security-session，引入如下依赖如下:
注意： 1、由于是web工程，packaging设置为war
2、使用tomcat7-maven-plugin插件来运行工程

<?xml version="1.0" encoding="UTF‐8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema‐instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven‐4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.jichi.security</groupId>
<artifactId>security‐session</artifactId>
<version>1.0‐SNAPSHOT</version>
<packaging>war</packaging>
<properties>
<project.build.sourceEncoding>UTF‐8</project.build.sourceEncoding>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring‐webmvc</artifactId>
<version>5.1.5.RELEASE</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet‐api</artifactId>
<version>3.0.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.8</version>
</dependency>
</dependencies>
<build>
<finalName>security‐springmvc</finalName>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7‐maven‐plugin</artifactId>
<version>2.2</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven‐compiler‐plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
<plugin>
<artifactId>maven‐resources‐plugin</artifactId>
<configuration>
<encoding>utf‐8</encoding>
<useDefaultDelimiters>true</useDefaultDelimiters>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
<includes>
<include>**/*</include>
</includes>
</resource>
<resource>
<directory>src/main/java</directory>
<includes>
<include>**/*.xml</include>
</includes>
</resource>
</resources>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
</project>

Spring容器配置

在config包下定义ApplicationConfig.java，它对应web.xml中ContextLoaderListener的配置。
这里除了springmvc的controller，都在这里配置。

servletcontext配置

本案例采用Servlet3.0无web.xml方式，在config包下定义WebConfig.java，它对应于DispatcherServlet配置。

加载spring容器

在init包下定义Spring容器初始化类SpringApplicationInitializer，此类实现WebApplicationInitializer接口， Spring容器启动时加载WebApplicationInitializer接口的所有实现类。

SpringApplicationInitializer相当于web.xml，使用了servlet3.0开发则不需要再定义web.xml， ApplicationConfig.class对应以下配置的application-context.xml，WebConfig.class对应以下配置的spring- mvc.xml，web.xml的内容参考：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mpiT6uZq-1592012273881)(https://img2020.cnblogs.com/blog/1534147/202005/1534147-20200521091134423-382572788.png)]

实现认证功能

认证页面

在webapp/WEB-INF/views下定义认证页面login.jsp，本案例只是测试认证流程，页面没有添加css样式，页面实现可填入用户名，密码，触发登录将提交表单信息至/login，内容如下：

在WebConfig中新增如下配置，将/直接导向login.jsp页面：

启动项目，访问/路径地址，进行测试

认证接口

用户进入认证页面，输入账号和密码，点击登录，请求/login进行身份认证。
（1）定义认证接口，此接口用于对传来的用户名、密码校验，若成功则返回该用户的详细信息，否则抛出错误异常：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BVATmbdo-1592012273886)(https://img2020.cnblogs.com/blog/1534147/202005/1534147-20200521091234708-1200737906.png)]

（2）认证实现类，根据用户名查找用户信息，并校验密码，这里模拟了两个用户：

（3）登录Controller，对/login请求处理，它调用AuthenticationService完成认证并返回登录结果提示信息：

（4）测试
启动项目，访问/路径地址，进行测试

实现会话功能

会话是指用户登入系统后，系统会记住该用户的登录状态，他可以在系统连续操作直到退出系统的过程。认证的目的是对系统资源的保护，每次对资源的访问，系统必须得知道是谁在访问资源，才能对该请求进行合法性拦截。因此，在认证成功后，一般会把认证成功的用户信息放入Session中，在后续的请求中，系统能够从Session 中获取到当前用户，用这样的方式来实现会话机制。
（1）增加会话控制
首先在UserDto中定义一个SESSION_USER_KEY，作为Session中存放登录用户信息的key。

然后修改LoginController，认证成功后，将用户信息放入当前会话。并增加用户登出方法，登出时将session置为失效。

（2）增加测试资源
修改LoginController，增加测试资源1，它从当前会话session中获取当前登录用户，并返回提示信息给前台。

（3）测试
未登录情况下直接访问测试资源/r/r1：

成功登录的情况下访问测试资源/r/r1：

测试结果说明，在用户登录成功时，该用户信息已被成功放入session，并且后续请求可以正常从session中获取当前登录用户信息，符合预期结果。

实现授权功能

现在我们已经完成了用户身份凭证的校验以及登录的状态保持，并且我们也知道了如何获取当前登录用户(从 Session中获取)的信息，接下来，用户访问系统需要经过授权，即需要完成如下功能：
匿名用户（未登录用户）访问拦截：禁止匿名用户访问某些资源。
登录用户访问拦截：根据用户的权限决定是否能访问某些资源。
（1）增加权限数据
为了实现这样的功能，我们需要在UserDto里增加权限属性，用于表示该登录用户所拥有的权限，同时修改 UserDto的构造方法。

并在AuthenticationServiceImpl中为模拟用户初始化权限，其中张三给了p1权限，李四给了p2权限。

（2）增加测试资源
我们想实现针对不同的用户能访问不同的资源，前提是得有多个资源，因此在LoginController中增加测试资源2。

（3）实现授权拦截器
在interceptor包下定义SimpleAuthenticationInterceptor拦截器，实现授权拦截：
1、校验用户是否登录 2、校验用户是否拥有操作权限

在WebConfig中配置拦截器，匹配/r/**的资源为受保护的系统资源，访问该资源的请求进入 SimpleAuthenticationInterceptor拦截器。

（4）测试
未登录情况下，/r/r1与/r/r2均提示 “请先登录”。
张三登录情况下，由于张三有p1权限，因此可以访问/r/r1，张三没有p2权限，访问/r/r2时提示 “权限不足 “。
李四登录情况下，由于李四有p2权限，因此可以访问/r/r2，李四没有p1权限，访问/r/r1时提示 “权限不足 “。
测试结果全部符合预期结果。
5.8.总结
基于Session的认证方式是一种常见的认证方式，至今还有非常多的系统在使用。我们在此小节使用Spring mvc技术对它进行简单实现，旨在让大家更清晰实在的了解用户认证、授权以及会话的功能意义及实现套路，也就是它们分别干了哪些事儿？大概需要怎么做？
而在正式生产项目中，我们往往会考虑使用第三方安全框架（如 spring security，shiro等安全框架）来实现认证授权功能，因为这样做能一定程度提高生产力，提高软件标准化程度，另外往往这些框架的可扩展性考虑的非常全面。但是缺点也非常明显，这些通用化组件为了提高支持范围会增加很多可能我们不需要的功能，结构上也会比较抽象，如果我们不够了解它，一旦出现问题，将会很难定位。