共计 2457 个字符，预计需要花费 7 分钟才能阅读完成。
在框架中，应用的鉴权模块是 spring security。
1 鉴权模块：gateway
gateway 的模块，波及到 http 方面的代码，因为是 webflux 架构，都与传统的 servlet 相差甚远，因而须要对 webflux 中应用的 reactor 响应式编程有肯定的理解。
spring security 最次要的利用模块是 gateway。这里治理了所有的 http 申请，所以在一个中型零碎中是最适宜鉴权的中央，同时 gateway 也是网关模块。
所有与鉴权相干的类都在包门路 cn.gateway.framework.security 下。
上面是对各个类的阐明。
1.1 AuthenticationManager
自定义用户鉴权治理类。
用于对自定义的 cn.framework.common.security.User 扩大字段的验证。
在此类中，校验了 credentialsBeenReset 这个自定义扩大字段，如果为 false，提醒前端用户须要进行明码重置，否则无奈持续登录。
1.2 LoginConverter
自定义的从 http 申请中获取登录信息的类。
在该类中，除了提供解析申请中的 username 和 password，还减少了对验证码的校验。
是否校验验证码，能够通过配置 gateway.login.verify.enable 抉择是否开启，默认不开启。
1.3 SecurityBeanConfig
spring security 须要用的 bean 在此类中定义。
目前只定义了两个 bean：
- PasswordEncoder 明码的加密形式
- ServerSecurityContextRepository，session 的保留地位
1.4 UserDetailsServiceImpl
用户信息的加载。
在这里定义了依据 username 获取用户信息。
因为用户信息的获取在 business-web 模块，凋谢 http 接口并不平安，所以应用了 redisson 提供的 RemoteService rpc 的形式调用，获取用户信息。
1.5 VerifyCodeController
获取验证的接口，调用此接口来判断是否开启验证码性能，同样是受到 gateway.login.verify.enable 的管制，默认不开启。
在胜利获取到验证码之后，会将验证码的代码保留到 websession 中，同时设置 websession 的最大无效工夫，也就是验证码的无效工夫，通过配置 gateway.login.verify.timeout 管制。
最初，只须要将验证码转化为 base64 返回给前台即可。
1.6 WebfluxSecurityConfig
此类是 spring security 开启的入口类，所有与 spring security 相干的配置都在这里实现。
下面的所有类，都是为此类服务的。
具体有如下性能。
- 设置 session 无效工夫，通过配置
gateway.session.max-interval-seconds管制 - 设置登录配置，在办法
setLogin，包含 url 门路，登录胜利后操作，登录失败后操作 - 设置登出配置，在办法
setLogout，包含 url 门路，登录胜利后操作 - 设置权限，在办法
setPermission，给 url 设置权限验证或者排除权限验证，除此之外，还可能灵便的设置权限，比方蕴含参数、申请办法、用户角色、用户资源清单等方面限度， 如果后续有垂直鉴权的需要，也是在此处实现
2 上游零碎
上游零碎指的是，所有申请都要通过 gateway 的零碎。
在改框架中，不对上游零碎做任何权限不便的设置，但还是依赖了 spring security 体系，起因有两个
- 避免当前有扩大需要，须要用到
- 须要不在代码层面接管来自网关的权限信息，可能通过框架天然实现连接
上游零碎的权限配置全副敞开，通过 framework:cn.framework.config.security.MvcSecurityHttpConfig 实现。
因为齐全没有权限验证机制，因而上游零碎必须敞开对外部的网络连接，所有的申请都必须通过网关，否则整个零碎等于没有权限验证。
在设计的过程中不是没有思考到，但在搭建的过程中进行了思考与对其它零碎的参考，认为没有开启的必要，如果须要开启，下面曾经提到过，曾经预留了开启形式。
3 认证信息传递
认证信息的生成与传递，全副由 spring security 主动实现，没有自定义代码参加。
认证信息的传递，蕴含了两种传递渠道
- 网关 -> 前台
- 网关 -> 上游
3.1 网关 -> 前台
一开始框架采纳的形式是应用 cookie 传递到前台，这也是 spring security 的默认传递形式。
然而这样做面临了很多问题。
- 日益严格的平安爱护，从浏览器到 axios 都对 cookie 进行了严格的限度，即便应用 csrf，也不能完全避免限度。
- IE 浏览器在跨域下对 cookie 反对有重大的问题，应用起来十分艰难
- 前台须要为保留 cookie 做很多定制化的革新
因而，框架中齐全摈弃 cookie 的应用，转而应用自定义 header 的形式，参数为 X-Auth-Token。
对此，spring security 曾经提供了配置的形式。
网关配置在 gateway:cn.gateway.framework.session.WebfluxHttpSessionConfig 类中。
3.2 网关 -> 上游
网关在接管到蕴含 X-Auth-Token 的申请后，会主动将 X-Auth-Token 转发到上游零碎中。
上游零碎为了可能不便的获取到认证信息，只须要与网关配置一样的认证信息形式。
上游零碎对立配置在 framework:cn.framework.config.session.MvcHttpSessionConfig 类中。
认证信息可能通过 framework:cn.framework.common.security.User#currentUserForMvc 办法不便的获取到认证信息。
如果须要扩大认证信息，比方带上用户机构、用户邮箱等信息，只须要扩大 User 和 UserDeserializer 两个类即可。