概述
本文讨论分布式架构权限管理的两种情况, 一种是针对统一授权访问的, 一种是跨平台接口访问的.
虽然分布式架构会做业务的切割, 将整体的业务切割为独立的子业务或者子平台, 但是同一平台下往往会有统一的授权和单点登录, 客户端而言平台是整体的, 这种是统一授权访问的权限管理. 但是也会遇到多平台协作的情况, 这种情况不用考虑其他平台的架构, 只需要为其提供数据接口跟其对接就可以, 这种情况就要考虑跨平台接口访问的权限管理.
一, 统一授权访问
前端采用 web 服务器, nginx 或者 haproxy 之类的都可以, 利用 nginx 做第一层反向代理, 用 zuul 做第二层反向代理, 两层反向代理对于常见的网络渗透和爬虫基本可以轻松应对. 在这个前提下, 我们处理接口授权和访问安全等问题, 而且需要从客户端和服务端都进行安全控制.
1, 用户通过用户名, 密码发起登陆请求, 这里可以配合验证码, 短信验证, 微信验证等提高安全级别, 登陆请求访问到权限中心的 ZUUL.
2, 由 ZUUL 反向代理到权限中心的 SERVICE.
3, 查询用户, 角色信息, 进行查询匹配.
4, 有查询结果以后反馈, 反馈用户状态, 用户, 角色, 权限信息等.
5, 生产 TOKEN,TOKEN 的算法需要自己编写, 建议加入时间戳等信息进行加密. 存放在 SESSION 或者直接放入 Redis 中, 一般建议放入 SESSION 中, 因为分布式架构要做 SESSION 共享, 必须有一个 SESSION 共享池, SESSION 共享池一般会用 Redis 来做, 而 SESSION 可以利用 SESSIONID, 确认唯一用户, 比较方便.
6, 返回给客户端用户, 角色, 权限信息.
7, 浏览器客户端通过得到的用户, 角色, 权限信息进行前端功能和菜单的渲染, 隐藏非授权的功能, 并且可以基于这些信息做前端的校验, 但是这种校验由于都在客户端, 很容易被人篡改, 只能做一些基本防护, 但是这是必要的.
8, 浏览器客户端发送业务请求到服务端, 请求会附带客户端菜单或者功能的权限信息, 服务端通过 ZUUL 的拦截器拦截业务请求, 访问 SESSION 共享池.
9, 然后通过 SESSIONID 得到 TOKEN 信息, 通过我们的 TOKEN 算法进行解密, 得到用户, 角色, 权限信息.
10, 进行匹配校验, 查看本次请求是否有接口访问权限, 校验通过就可以访问接口, 校验不通过就不能访问.
二, 跨平台接口访问
这里的接口是指一下跨平台的接口服务, 类似 webservice 这样, 没有单点登录, 没有统一的授权, 往往是其他平台跟我们平台进行远程交互的, 这些往往两个平台不是统一的公司或部门, 所以接口不是长期使用的, 有一定的时间限制.
1, 用户管理员配置外部客户端用户及其权限信息.
2, 添加用户信息, 权限信息到用户数据库之中.
3, 外部客户端接口如果没有 TOKEN, 需要先发送授权请求到权限中心.
4, 权限中心通过验证是否配置外部客户端用户, 并且取得该用户的权限信息, 校验通过以后通过加密算法生产 TOKEN, 这里的 TOKEN 根据实际情况, 如果安全要求高最好加入时间戳, 让 TOKEN 过期作废, 让对方重新请求.
5, 将 TOKEN 存入 Redis 中, 形成 TOKEN 共享池, 这里由于没有浏览器的 SESSIONID, 所以存放在 SESSION 中意义不大.
6, 返回 TOKEN 给客户端.
7, 客户端拿到 TOKEN 以后发送业务请求给业务接口地址.
8, 业务接口通过 ZUUL 拦截请求, 并且将 TOKEN 跟 Redis 的 TOKEN 进行比对.
9, 比对成功以后, 对 TOKEN 进行解密, 然后看是否有接口授权.
10, 如果有接口授权则通过, 访问接口, 如果没有则不能访问.
Java 高级资料需要自己领取, 涵盖了 Java,Redis,MongoDB,MySQL,Zookeeper,Spring Cloud,Dubbo 高并发分布式等教程!!!
来源: http://developer.51cto.com/art/201907/599865.htm