Spring Security 笔记

1、自定义用户认证逻辑

2、个性化用户认证流程(一)

3、认证流程源码级详解

  • AuthenticationManager 管理所有的Provider,并选择适合的进行验证,
  • AuthenticationProvider 验证提供者,可以自己写provider处理自己的业务场景逻辑

SecurityContextPersistenceFilter 实现认证结果在多个请求之间共享

1、请求进来的时候,检查session里是否有SecurityContext认证信息,如果有就放到线程里

2、请求反回来的时候,检查线程里是否有SecurityContext认证信息,如果有就放到sesiion里

4、4-7 图片验证码

5、4-8 图片验证码重构

4-9 添加记住我功能

4-10 短信验证码接口开发

4-11 短信登录开发

4-12 短信登录配置及重构

5-1 OAuth协议简介

传统方式-使用密码用户

导致问题

OAuth解决方法

一般流程

授权模式流程

 

5-2 SpringSocial简介

OAuth2Operations(OAuth2Template) : 封装了1-5的步骤
Api(AbstractOAuth2ApiBinding): 对第6步提供了支持


Connection (OAuth2Connection) :包含用户信息的对象,
ConnectionFactory(OAuth2ConnectionFactory) 
    ServiceProvider :创建Connection,要走1-5的流程,所以包含ServiceProvider
    ApiAdapter OAuth2Connection:是固定结构的数据,对第三方api返回的数据进行匹配;读取用户信息

UseConnection:保存服务提供的信息与业务系统中的用户的关联

    UsersConnectionRepository(JdbcUsersConnectionRepository)负责 操作这个数据库中的表

5-5 开发QQ登录(下)

5-9 单机Session管理

5-10 集群Session管理

5-11 退出登录

6-1 SpringSecurityOAuth简介

OAuth协议:第三方认证的协议规则,

Spring Social:基于OAuth协议的第三方认证框架

Spring Security OAuth : 可以解决传统方式带来的问题(第三方cookie问题)

SpringSecurityOAuth封装了服务提供商大部分的操作(相当于QQ,weix);而social则是封装了客户端和服务提供商交互的流程

传统方式:基于session

  • 开发繁琐 
    • 基于cookie:传统方式是容器和浏览器自动处理的cookie
  • 安全性和客户体验差
  • 有些前端技术不支持cookie,如小程序

基于token方式:oauth 
    * 参数中携带token 
    * 可以对token更大程度的控制

使用cookie带来的问题

OAuth协议带来的问题

Spring Security OAuth框架介绍

6-2 实现标准的OAuth服务提供商

地址是提供给第三方应用引导认证授权的,clientid用来是识别哪个应用在申请认证,basic登录是表示请求那个用户给予授权,scope是请求用户给予什么授权

6-3 SpringSecurityOAuth核心源码解析

TokenEndpoint :整个流程入口点
ClentDetailsService : 读取第三方应用信息
TokenRequest : 封装了提交的参数信息
TokenGranter : 令牌授权者,找到一个授权模式(grant_type)进行处理都会产出两个对象 
  1、OAuth2Request :处理之后的新对象
  2、Authentication : 谁在授权的信息,对应用户信息(根据提交的信息查询到的用户信息,不同的模式获取的用户信息不同)
OAuth2Authentication : 哪一个用户在对哪一个应用进行授权,对前面信息的封装
AuthorizationServerTokenServices: 
TokenStore : 令牌存储
TokenEnhancer :令牌加强器,可以对令牌进行改造加强

6-4 重构用户名密码登录

6-5 重构短信登录

6-6 重构社交登录

简化模式

授权码模式

内部做了封装流程简化

6-8 令牌配置

6-9 使用JWT替换默认令牌

6-10 基于JWT实现SSO单点登录

7-1 SpringSecurity授权简介

7-2 SpringSecurity源码解析

  • FilterSecurityInterceptor

    决定该用户是否有权限访问指定的资源

  • ExceptionTranslationFilter

    异常处理,如果不能访问,则处理FilterSecurityInterceptor中抛出的异常

  • AnonymousAuthenticationFilter : 匿名过滤器,位置固定,前面所有的都走完之后,会经过该过滤器

// 如果之前没有身份认证 则创建一个 AnonymousAuthenticationToken 也就是说到达 FilterSecurityInterceptor 中的时候一定有一个身份信息

 

 

  • FilterSecurityInterceptor
  • AccessDecisionManager 
  1.      AffirmativeBased 只要有一个同意则放行(默认使用)在未登录的时候用的是只要有一个拒绝则不能访问,在登录            后,只要有一个允许则放行
  2.     ConsensusBased 通过/不通过 哪一个票数多就遵循哪一个
  3.     UnanimousBased 只要有一票否决则不允许访问
  • AccessDecisionVoter 投票者  就是用来一系列的判定,是否可以进行访问什么的。spring3-,由一堆实现类来解决 
  1. WebExpressionVoter spring3+ 由该类全部包办,它投过就过,不过就不过

——– 以上是三个核心的类———

  • SecurityConfig 所有的配置信息
  • ConfigAttribute 对应了每一个url的配置信息
  • SecurityContextHolder
  • Authentication 用户身份信息,用户拥有的权限信息

主流程:拿到 配置信息,用户身份信息,请求信息 然后给投票者进行投票;最后根据策略进行决定是否放行

从两个流程进行分析:未登录访问被拦截 ,登录后访问

7-3 权限表达式

自定义权限表达式

.antMatchers("xx").access("hasRole('ROLE_USER') and hasRole('ROLE_SUPER')")

分离业务配置

思路:

  • 提供AuthorizeConfigProvider接口
  • 权限模块的通用配置实现该接口,然后进行配置
  • 其他的应用或则模块配置可以自己实现
  • 最后使用 AuthorizeConfigManager类来从spring获取并管理所有的AuthorizeConfigProvider实现
  • 拿到所有的配置后,进行统一设置

7-4 基于数据库Rbac数据模型控制权限

 

Guess you like

Origin blog.csdn.net/qq_30436011/article/details/106134253