SpringSecurity结构分析

Springsecurity整体分为两部分：认证（Authentication）与授权（Authorization）

整个结构要重点分析SecurityConfig extends WebSecurityConfigurerAdapter

2是登录认证前的放行，即无需登录认证即可访问的url

1是登录认证过滤器，通常采用户名密码的方式进行身份认证

3是认证后的权限校验，采用加法的方式，即配置了哪些url需要角色，才进行访问权限的判断；没有配置的，即默认无需权限即可访问。

3通常采用RBAC模型，即用户、角色、资源、用户角色关联、角色资源管理，资源即Url。所谓的权限判断，即看访问url所需的角色。

4是认证过后，生成jwt token，以后每次访问url，只判断jwt token即可，方便省事，无需存储状态

5是禁用session，采用jwt，因为目前大部分应用都是前后端分离模式，本身无需保存状态。

Jwt验证：

1是jwt为空，即还没有进行登录认证，也是要放行的，因为系统存在不需要登录认证即可访问的url，这些url配置在白名单中。

2是jwt不为空，那么要进行jwt验证，解析claim解出account，判断jwt是否过期，判断account是否存在，等等。

3、是查询权限，构建usernamepasswordauthenticationtoken；后边在AccessDecisionManager中取出角色进行权限判断

1是解析出url

2是根据url查询出访问该url所需的角色

如果角色为空，说明该url任何人都可以访问；如果角色不为空，将角色构建Collection并返回

1是取出jwt验证环境放入的当前用户的权限

2是根据FilterSecurityMetadataSource查询出的访问url所需要的角色信息，基于1的角色，判断二是是否匹配

匹配则说明用户有权访问url，不匹配则说明没有权限访问。

登录认证

用户名密码加密存储进入数据库：

BCryptPasswordEncoder 加密解密实现

用户登录进入系统接口：

获取用户名密码+解密，重写UserDetailsService方法通过验证数据库中的用户名密码；

如果密码正确，根据userid生成token,发送给前端进行存储,并把userid:用户信息，这样的键值对存入redis池;

用户进行其他请求时，携带token

认证过滤器：后端接受到前端传递的token,对token里面解析出来是userid;使用userid去redis中获取对应的用户信息LoginUser对象，

redis对象存在,证明当前用户存在，并且已经登录，放行请求；不存在禁止访问当前请求接口

用户注销

后盾根据SecurityContextHolder中的认证信息（类似于gin中的上下文)，可以直接获取userid,操作redis池，删除对应的userid键值对

代码内容，后面放github地址

授权

每个接口都有限制访问资源所需权限

使用rbac权限模型来存储每个用户拥有的权限，

用户表--角色表：多对多中间表

角色表--权限表：多对多中间表

通过用户id，多表联查，查出改用户拥有的权限列表[]

未登录的用户：用户登录时，用户密码验证数据库通过，生成的用户对象存在SecurityContextHolder中，同时把userid和权限列表[]存入redis缓存中（留给该用户请求其他接口时进行验证）；

已经登录的用户：发起对应接口的请求，查询redis中改用户的权限与当前接口权限比较，如果拥有，就通过；没有就返回权限不足进行拦截