金湖县建设工程质量监督网站,轻淘客一键做网站,免费软件编程入门自学,网络推广的方法有Spring Security OAuth2.0 实现分布式系统的认证和授权 1. 基本概念1.1 什么是认证#xff1f;1.2 什么是会话#xff1f;1.2.1 基于 session 的认证方式1.2.2 基于 token 的认证方式 1.3 什么是授权#xff1f;1.3.1 授权的数据模型 1.4 RBAC 介绍 2. Spring Security2.1 S… Spring Security OAuth2.0 实现分布式系统的认证和授权 1. 基本概念1.1 什么是认证1.2 什么是会话1.2.1 基于 session 的认证方式1.2.2 基于 token 的认证方式 1.3 什么是授权1.3.1 授权的数据模型 1.4 RBAC 介绍 2. Spring Security2.1 Spring Security 介绍2.2 Spring Security 工作原理2.2.1 结构总览2.2.2 认证的流程2.2.2.1 认证流程2.2.2.2 AuthenticationProvider 介绍2.2.2.3 UserDetailsService 介绍2.2.2.4 PasswordEncoder 介绍 2.2.3 授权流程2.2.3.1 授权流程2.2.3.2 授权决策 2.2.4 会话2.2.5 授权2.2.5.1 web授权2.2.5.1 方法授权 3.分布式系统认证方案3.1 什么是分布式系统3.2 分布式认证需求3.3 分布式认证方案3.3.1 选型分析3.3.2 技术方案 4. OAuth 2.04.1 OAuth2.0 介绍4.2 Spring Cloud Security OAuth 2.04.2.1 环境介绍 5.Spring Security OAuth2.0 实现分布式系统认证和授权示例源码参考文献 1. 基本概念
1.1 什么是认证
为什么要认证
认证是为了保护系统的隐私数据和资源。
什么是认证
判断用户的身份是否合法的过程。
常见的认证方式有哪些
用户名密码登录二维码登录手机短信登录指纹认证
1.2 什么是会话
什么是会话
会话就是系统为了保持当前用户的登录状态所提供的机制。
常见的会话机制
基于 session 的方式基于 token 的方式
两种实现方式的对比
基于 session 的认证方式由 Servlet 规范定制服务器要存储 session 信息要占用内存资源客户端需要支持 cookie 基于 token 的认证方式则一般不需要服务器存储 token并且不限制客户端的存储方式。
如今移动互联网时代更多类型的客户端需要接入系统系统多是采用前后端分离的架构实现所以基于 token 的方式更适合。
1.2.1 基于 session 的认证方式
基于 session 的认证方式如下图
基于 session 的认证交互流程
用户认证成功后在服务端生成用户相关的数据保存在 session(当前会话) 中发给客户端 的 session_id 存放到 cookie 中, 这样用户客户端请求时带上 session_id 就可以验证服务端是否存在 session 数据以此完成用户的合法校验当用户退出系统或 session 过期销毁时客户端的 session_id 也就无效了。
1.2.2 基于 token 的认证方式
基于 token 的认证方式如下图
基于 token 的认证交互流程
用户认证成功后服务端生成一个 token 发给客户端客户端可以放到 cookie 或 localStorage 等存储中每次请求时带上 token服务端收到 token 通过校验后即可确认用户身份。
1.3 什么是授权
为什么要授权
是为了更细粒度的对隐私数据进行划分。
什么是授权
授权是用户认证通过根据用户权限来控制用户访问资源的过程拥有资源的访问权限则正常访问没有权限则拒绝访问。
1.3.1 授权的数据模型
授权可以简单的理解为 Who 对 What(Which) 进行 How 操作。
关键的概念
Who即主体(Subject)主体一般是用户也可以是程序需要访问系统中的资源。What即资源(Resource)系统菜单、页面、按钮、代码方法、系统商品信息、系统订单信息等。系统菜单、页面、按钮、代码方法都属于系统功能资源对于web系统每个功能资源通常对应一个URL系统商品信息、系统订单信息都属于实体资源(数据资源)实体资源由资源类型和资源实例组成比如商品信息为资源类型商品编号为 001 的商品为资源实例。How权限/许可(Permission)规定了用户对资源的操作许可权限离开资源没有意义如用户查询权限、用户添加权限、某个代码方法的调用权限、编号为 001 的用户的修改权限等通过权限可知用户对哪些资源都有哪些操作许可。
主体、资源、权限关系如下图
主体、角色、权限关系如下图
1.4 RBAC 介绍
如何实现授权
业界通常基于 RBAC 的实现授权。
基于角色的访问控制
RBAC 基于角色的访问控制 (Role Based Access Control) 是按角色授权。
例如主体的角色为总经理可以查询企业运营报表查询员工工资信息等访问控制流程如下
当需要修改角色的权限时就需要修改授权相关的代码系统的可扩展性差。
基于资源的访问控制
RBAC 基于资源的访问控制 (Resource Based Access Control) 是按资源(或权限)进行授权。
优点系统设计时定义好查询工资的权限标识即使查询工资所需要的角色变化为总经理和部门经理也不需要修改授权代码系统的可扩展性强。
2. Spring Security
2.1 Spring Security 介绍
Spring Security 是一个能够为基于 Spring 的企业级应用系统提供声明式的安全访问控制解决方案的安全框架。由于它是 Spring 生态系统中的一员因此它伴随整个 Spring 生态系统不断修正、升级在 Spring Boot 项目中加入 Spring Security 更是十分简单使用 Spring Security 减少了为企业系统安全控制编写大量重复代码的工作。
2.2 Spring Security 工作原理
2.2.1 结构总览
Spring Security 所解决的问题就是安全访问控制而安全访问控制功能其实就是对所有进入系统的请求进行拦截校验每个请求是否能够访问它所期望的资源。一般实现的方式有 Filter 和 AOP。Spring Security 对 web 资源的保护是靠 Filter 实现的。
当初始化 Spring Security 时会创建一个名为 SpringSecurityFilterChain 的 Servlet 过滤器类型为 org.springframework.security.web.FilterChainProxy, 它实现了 javax.servlet.Filter, 因此外部的请求会经过此类。
Spring Security 过滤器链结构
AuthenticationManager用于用户认证AccessDecisionManager用于权限校验
FilterChainProxy 是一个代理真正起作用的是 FilterChainProxy 中 SecurityFilterChain 所包含的各个 Filter同时这些 Filter 作为 bean 被 Spring 管理它们是 Spring Security 的核心各有各的职责但它们并不直接处理用户的认证也不直接处理用户的授权而是把它们交给了认证管理器 (AuthenticationManager)和决策管理器 (AccessDecisionManager) 进行处理。
FilterChainProxy相关类的UML
Spring Security 功能的实现主要是由一系列的过滤器链相互配合完成
SecurityContextPersistenceFilter这个 Filter 是整个拦截过程的入口和出口 (也就是第一个和最后一个拦截器)会在请求开始时从配置好的 SecurityContextRepository 中获取 SecurityContext然后把它设置给 SecurityContextHolder。在请求完成后将 SecurityContextHolder 持有的 SecurityContext 再保存到配置好的 SecurityContextRepository同时清除 SecurityContextHolder 所持有的 SecurityContext。UsernamePasswordAuthenticationFilter用于处理来自表单提交的认证该表单必须提供对应的用户名和密码。其内部还有登录成功或失败后进行处理的 AuthenticationSuccessHandler 和 AuthenticationFailureHandler这些都可以根据需求做相关的改变。FilterSecurityInterceptor 是用于保护 web 资源的使用 AccessDecisionManager 对当前用户进行授权访问。ExceptionTranslationFilter能够捕获来自 FilterChain 的所有异常并进行处理但是它只会处理两类异常AuthenticationException 和 AccessDecisionException其他的异常它会继续抛出。
2.2.2 认证的流程
2.2.2.1 认证流程 用户提交用户名、密码被 SecurityFilterChain 中的 UsernamePasswordAuthenticationFilter 过滤器获取到封装为请求 Authentication通常情况下是 UsernamePasswordAuthenticationToken 这个实现类。然后过滤器将 Authentication 提交至认证管理器 (AuthenticationManager) 进行认证认证成功后 AuthenticationManager 身份管理器返回一个被填充了信息的 (包括上面提供的权限信息、身份信息、细节信息、但密码通常会被移除)Authentication 实例。SecurityContextHolder 安全上下文容器将第3步填充了信息的 Authentication 通过 SecurityContextHolder.getContext().setAuthentication() 方法设置到其中。
AuthenticationManager 接口(认证管理器) 是认证相关的核心接口也发起认证的出发点他的实现类为 ProviderManager。而 Spring Security 支持多种认证方式因此 ProviderManager 维护着一个 ListAuthenticationProvider 列表存放多种认证方式最终实际的认证工作是由 AuthenticationProvider 完成的。
Web 表单的对应的 AuthenticationProvider 实现类为 DaoAuthenticationProvider 它的内部又维护着一个 UserDetailsService 负责 UserDetails 的获取。最终 AuthenticationProvider 将 UserDetails 填充至 Authentication。
认证核心组件的大体关系
2.2.2.2 AuthenticationProvider 介绍
AuthenticationProvider 处理了认证的逻辑它会去比对 UserDetailsService 提取到的用户密码和用户提供的密码是否一致。认证通过会将 Authentication(UsernamePasswordAuthenticationToken实现) 返回。
2.2.2.3 UserDetailsService 介绍
UserDetailsService 负责根据用户名提取用户信息 UserDetails(包含密码) 可以通过将自定义的 UserDetailsService 公开为 spring bean 来定义自定义身份验证。
2.2.2.4 PasswordEncoder 介绍
常见的 PasswordEncoder
BCryptPasswordEncoderPbkdf2PasswordEncoderSCryptPasswordEncoder
2.2.3 授权流程
2.2.3.1 授权流程
Spring Security 可以通过 http.authorizeRequests() 对 web 请求进行授权保护。Spring Security 使用标准 Filter 建立了对 web 请求的拦截最终实现对资源的授权访问。
Spring Security 的授权流程
授权相关主要的过滤器
FilterSecurityInterceptor: 获取资源所需要的权限、用户所具有的权限SecurityMetadataSource:AccessDecisionManager: 对比获取资源所需要的权限和用户所具有的权限
授权流程
拦截请求已认证用户访问受保护的web资源将被SecurityFilterChain中的FilterSecurityInterceptor 的子类拦截。获取资源访问策略FilterSecurityInterceptor 会从 SecurityMetadataSource 的子类 DefaultFilterInvocationSecurityMetadataSource 获取要访问当前资源所需要的权限 CollectionConfigAttribute。最后FilterSecurityInterceptor会调用 AccessDecisionManager 进行授权决策若决策通过则允许访问资源否则将禁止访问。
2.2.3.2 授权决策
AccessDecisionManager 采用投票的方式来确定是否能够访问受保护资源的权限。
SpringSecurity 内置了三个基于投票的 AccessDecisionManager实现类, 默认使用 AffirmativeBased
AffirmativeBasedConsensusBasedUnanimousBased
AffirmativeBased 执行逻辑
只要 AccessDecisionVoter的投票为 ACCESS_GRANTED 则同意用户进行访问如果全部弃权也表示通过如果没有一个人投赞成票但是有人投反对票则将抛出 AccessDeniedException.
ConsensusBased 执行逻辑
如果赞成票多余反对票则表示通过反过来如果反对票多于赞成票则将抛出 AccessDeniedException如果赞成票与反对票相同且不等于 0并且属性 allowIfEqualGrantedDeniedDecisions 的值为 true,则表示通过否则将抛出异常 AccessDeniedException。参数 allowIfEqualGrantedDeniedDecisions 默认值为 true如果所有的 AccessDecisionVoter 都弃权了则将视参数 allowIfAllAbstainDecisions 的值而定如果该值为true则表示通过否则将抛出异常 AccessDecisionException参数 allowIfAllAbstainDecisions 的值默认为 false.
UnanimousBased 执行逻辑
如果受保护对象配置的某一个 ConfigAttribute 被任意的 AccessDecisionVoter 反对了则将抛出 AccessDeniedException。如果没有反对票但是有赞成票则表示通过。如果全部弃权了则将视参数 allowIfAllAbstainDecisions 的值而定true 则通过false 则抛出 AccessDeniedException。
Spring Security 也内置了一些投票者实现类
RoleVoterAuthenticatedVoterWebExpressionVoter
2.2.4 会话
用户认证通过后为了避免用户的每次操作都进行认证可将用户的信息保存在会话中。
Spring Security 提供会话管理认证通过后将身份信息放入 SecurityContextHolder 上下文SecurityContext 与当前线程进行绑定方便用户获取用户身份。
会话机制
always如果没有 session 存在就创建一个ifRequired如果需要就创建一个 Session (默认) 登录时。neverSpring Security 将不会创建 session 但是如果应用中其他地方创建了 session 那么Spring Security 将会使用它。statelessSpring Security 将绝对不会创建 session也不会使用session
默认情况下Spring Security 会为每个登录成功的用户新建一个 session 就是 IfRequired
stateless 适用于 Rest API 及其无状态认证机制。
安全会话cookie
httpOnly: 如果为 true,浏览器脚本将无法访问 cookiesecure: 如果为 true, 则 cookie 将仅通过 HTTPS 连接发送
2.2.5 授权
授权的方式包括 web 授权和方法授权web 授权是通过 url 拦截进行实现方法授权是通过方法拦截进行授权。他们都会调用 accessDecisionManager 进行授权决策若为 web 授权则拦截器为 FilterSecurityInterceptor若为方法授权则拦截器为 MethodSecurityInterceptor。如果同时通过 web 授权和方法授权则先执行 web 授权执行方法授权。最后决策通过则允许访问资源否则将禁止访问。
授权方式
web 授权通过 url 拦截授权方法授权 通过方法拦截授权
2.2.5.1 web授权
推荐使用基于资源的授权。 配置权限拦截时应该将具体的权限拦截放到正则表达式的拦截前。
http.authorizeRequests() 保护 URL 常用的方法
authenticated() 保护 URL需要用户登录permitAll() 指定 URL 无需保护一般应用与静态资源文件hasRole(String role) 限制单个角色访问角色将被增加 “ROLE_”,所以 “ADMIN” 将和 “ROLE_ADMIN” 进行比较。hasAuthority(String authority) 限制单个权限访问hasAnyRole(String… roles) 允许多个角色访问hasAnyAuthority(String… authorities) 允许多个权限访问access(String attribute) 该方法使用 SpEL 表达式所以可以创建复杂的限制haslpAddress(String ipaddressExpression) 限制IP地址或子网
2.2.5.1 方法授权
从 Spring Security 2.0 版本开始它支持服务层方法的安全性的支持
PreAuthorize 方法执行前拦截PostAuthorize 方法执行后拦截Secured
可以在任何 Configuration 实例上使用 EnableGlobalMethodSecurity 注释来启用基于注解的安全性。
Secured 使用
Secured(“IS_AUTHENTICATED_ANONYMOUSLY”) 不需要登录就可以访问Secured(“ROLE_TELLER”)需要角色为 TELLER 才可以访问
PreAuthorize 使用
PreAuthorize(“hasAuthority(‘p1’)”)拥有p1 权限才可以访问
3.分布式系统认证方案
3.1 什么是分布式系统
随着软件环境和需求的变化软件的架构由单体结构演变为分布式架构具有分布式架构的系统叫分布式系统。
分布式系统的运行通常依赖网络它将单体结构的系统分为若干服务服务之间通过网路交互来完成用户的业务当前流行的微服务架构就是分布式系统架构。
分布式系统架构
分布式系统的特点
分布性每个部分都可以独立部署服务之间交互通过网络进行通信。伸缩性每个部分都可以集群方式部署并可针对部分节点进行硬件及软件扩容具有一定的伸缩能力共享性每个部分都可以作为共享资源对外提供服务多个部分可能有操作共享资源的情况。开放性每个部分根据需求都可以对外发布共享资源的访问接口并可允许第三方系统访问。
3.2 分布式认证需求
分布式系统的每个服务都会有认证、授权的需求如果每个服务都实现一套认证授权逻辑会非常冗余考虑分布式系统共享性的特点需要由独立的认证服务处理系统认证授权的请求;考虑分布式系统开放性的特点不仅对系统内部服务提供认证对第三方系统也要提供认证。
分布式认证的需求总结
统一认证授权应用接入认证
统一认证授权
提供独立的认证服务统一处理认证授权。 无论是不同类型的用户还是不同种类的客户端(web端、H5、APP),均采用一致的认证、权限、会话机制实现统一认证授权。 要实现统一则认证方式必须可扩展支持各种认证需求比如用户名密码认证、短信验证码、二维码、人脸识别等认证方式并可以非常灵活的切换。
应用接入认证
应提供扩展和开放的能力提供安全的系统对接机制并可开放部分 API 给接入第三方使用一方应用(内部系统服务)和三方应用(第三方应用)均采用统一机制接入。
3.3 分布式认证方案
3.3.1 选型分析
1.基于 Session 的认证方式
Session 复制Session 黏贴Session 集中存储
总的来说基于 session 认证的认证方式可以更好的在服务端对会话进行控制且安全性较高但是 session 机制方式基于 cookie在复杂多样的移动客户端上不能有效的使用并且无法跨域另外随着系统的扩展需提高 session 的复制、黏贴及存储的容错性。
2.基于token的认证方式
基于 token 的认证方式服务端不用存储认证数据易维护扩展性强客户端可以把token存在任意地方并且可以实现 web 和 app 统一认证机制。其缺点也很明显token 由于自包含信息因此一般数据量较大而且每次请求都需要传递因此比较占带宽另外token的签名操作也会给 cpu 带来额外的处理负担。
3.3.2 技术方案
根据选型的分析决定采用基于 token 的认证方式它的优点是
适合统一认证的机制客户端、一方应用、三方应用都遵循一致的认证机制。token 认证方式对第三方应用的接入更适合因为它更开放可使用当前有流行的开放协议 Oauth 2.0 、JWT 等。一般情况下服务端无需存储会话信息减轻了服务器的压力。
分布式系统认证技术方案
分布式系统认证流程描述
用户通过接入方(应用)登录接入方采取 OAuth2.0 方式在统一认证服务中认证认证服务调用验证该用户的身份是否合法并获取用户权限信息。认证服务获取接入方权限信息并验证接入方是否合法。若登录用户以及接入方都合法认证服务生成 jwt 令牌返回给接入方其中 jwt 中包含了用户权限及接入方权限。后续接入方携带 jwt 令牌通过网关对微服务资源进行访问。网关对令牌解析、并验证接入方的权限是否能够访问本次请求的微服务。如果接入方的权限没问题网关将原请求header中附加解析后的明文Token并将请求转发至微服务。微服务收到请求明文token中包含登录用户的身份和权限信息。因此后续微服务自己可以干两件事1用户授权拦截看当前用户是否有权访问该资源2将用户信息存储进当前线程上下文有利于后续业务逻辑随时获取当前用户信息
流程所涉及到认证服务、网关这两个组件职责如下
统一认证服务它承载了OAuth2.0接入方认证、登入用户的认证、授权以及生成令牌的职责完成实际的用户认证、授权功能。网关作为系统的唯一入口网关为接入方提供定制的API集合它可能还具有其它职责如身份验证、监控、负载均衡、缓存等。网关方式的核心要点是所有的接入方和消费端都通过统一的网关接入微服务在网关层处理所有的非业务功能。
4. OAuth 2.0
4.1 OAuth2.0 介绍
OAuth (开放授权) 是一个开放标准允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息而不需要将用户名和密码提供给第三方应用或分享他们数据的所有内容。
OAuth 2.0 是 OAuth 协议的延续版本但不向后兼容 OAuth 1.0即完全废止 OAuth 1.0。
OAuth2.0 认证过程
OAuth 4.0 角色
客户端本身不存储资源需要通过资源拥有者的授权去请求资源服务器的资源。资源拥有者通常为用户也可以是应用程序即该资源的拥有者。授权服务器用于服务提供商对资源拥有的身份进行认证、对访问资源进行授权认证成功后会给客户端发放令牌作为客户端访问资源服务器的凭据。资源服务器存储资源的服务器。
现在还有一个问题服务提供商能允许随便一个客户端就接入到他们的授权服务器吗答案是否定的服务提供商会给准入的接入方一个身份用于接入时的凭据
client_id: 客户端标识client_secret: 客户端密钥
因此准确的来说授权服务器对两种 OAuth2.0 中的两个角色进行认证授权分别是 资源拥有者、客户端。
4.2 Spring Cloud Security OAuth 2.0
4.2.1 环境介绍
Spring-Security-OAuth2.0 是对 OAuth2.0 的一种实现并且和 Spring Security 相辅相成与 Spring Cloud 体系的集成也非常便利。
OAuth 2.0 的服务提供方涵盖两个服务
授权服务(Authorization Server也叫认证服务)资源服务(Resource Server)
授权服务(Authorization Server也叫认证服务)应包含对接入端以及用户的合法性进行验证并颁发 token 等功能。对令牌的请求端点由 Spring MVC 控制器实现下面是配置一个认证服务必须要 实现的 endpoint
AuthorizationEndpoint服务用于认证请求。默认 URL /oauth/authorizeTokenEndpoint服务于访问令牌的请求。默认 URL /oauth/token
资源服务(Resource Server)应包含对资源的保护功能对非法请求进行拦截对请求中 token 进行解析鉴权等下面的过滤器用于实现 OAuth 2.0 资源服务
OAuth2AuthenticationProcessingFilter 用来对请求给出的身份令牌解析鉴权。
认证流程
客户端请求授权服务进行认证认证通过后由授权服务颁发令牌客户端携带令牌 token 请求资源服务资源服务器校验令牌的合法性合法即返回资源信息。
5.Spring Security OAuth2.0 实现分布式系统认证和授权示例源码
Spring Cloud Alibaba 集成 Spring Security OAuth2.0源码
参考文献
黑马程序员 OAuth2.0官方文档
