共计 2389 个字符,预计需要花费 6 分钟才能阅读完成。
背景:
门户网站分为个人用户,集体开发者,机构用户,页面不同的操作须要特定的用户能力操作。如 api 申请,密钥下载只有机构用户才可操作,重置明码须要登录后才可操作。
治理端分为系统管理员,开放平台管理员,银行管理员,不同的角色具备不同的权限,
权限按资源划分
服务间调用也须要进行爱护,如调用发送短信接口,调用发送站内信的接口,不能不加限度地对外裸露。
因而须要以接口为粒度进行对立鉴权,在接口处注明须要的权限,需注明申请起源:门户,治理端,服务间调用。如果是门户或治理端,还可标注须要的角色或资源。可校验多个起源。
技术设计:
对于门户网站和治理端,用户登录胜利后生成蕴含用户信息(userId)的 JWT token,前端保留在 vuex 中。每次操作申请将 token 放入 front- Authorization 和 manage- Authorization 以供服务端校验。其中 front 和 manage 代表源自门户和治理端。
服务间调用发送 http 申请时,在 header 处增加 service- Authorization,值为有效期为 30s 的 JWT token,service 代表源自服务间调用。
通过注解标记须要校验的接口,并增加所须要的申请起源和资源名称,如果匹配则放行,否则报无权限申请。
利用拦截器对申请进行切面操作,如果该办法加 @AuthRequest 注解则寻找 header,若蕴含 front- Authorization,manage- Authorization 或 service- Authorization,则对该 token 进行 JWT 校验。其中 front 和 service 校验较为简单,间接校验即刻,manage 校验 token 胜利后还需从 token 中获取 userId,通过服务间调用判断该用户是否领有该资源。如果门户和治理端校验胜利,从 token 中取出 userId,role 放入 attribute,供接口应用。
引入该包还为 feign 调用增加 service- Authorization 的 header
流程图:
阐明:
门户网站,治理端和服务间调用通常通过 gateway,然而对立校验不在 gateway,而在各自服务,起因如下:
- 更平安,有的申请可能间接通过服务调用,而非 gateway,因而须要在服务的接口层面做校验
- 配置更不便
权限是一种安全策略,用户只可拜访被受权的资源。因而须要采取策略管制用户的行为。
波及到以下几个方面:
- 用户认证:如何校验用户的合法性并保留用户的登录状态
- 权限校验:如何爱护服务端的接口,用户是否有资格调用接口,包含:从 web 端发送来的申请,服务间的调用
- 权限治理:如何给用户分配资源,RBAC
权限性能在服务从单体转向微服务架构面临如下挑战:
- 如何保障用户的登录状态。单体中可将登录状态保留至 session 中,但微服务中利用被分为多个服务,服务应该是无状态的,不能保留用户的登录状态;
- 微服务拆分后,调用起源不仅仅是客户端,还有来自服务间的调用,因而须要全面思考多个起源的调用
- 权限校验性能不能散落在各个服务中,应对立解决
- 前后端拆散,只做数据交互,前端路由 / 按钮资源化,如何治理资源
微服务利用的权限性能应具备特点:
- 与业务零碎解耦,性能独立,职责繁多
- 保障可用性,当权限服务不可用时,不能扭转业务零碎的行为
- 保障性能,防止因鉴权导致响应工夫减少
- 对已有代码侵入性小,革新不便
现有的解决方案:
- Oauth2:受权框架
- JWT token:认证协定
- Security:有些重
- Shiro:可做权限认证,明码加密等,但不太实用于微服务环境,SecurityManager
- 分布式 session:将 username,session id 作为 key 存储至分布式存储中,用户拜访微服务时,能够从分布式存储中断定。保障了高可用和可扩大。毛病是存在安全隐患。
通过比拟,决定自行研发一套权限校验框架,包含:
- JWT Token 进行用户认证及鉴权
- RBAC 权限调配体系
架构图:
Token 设计
一段字符串,用户登陆胜利后服务端生成返回至客户端保留,作为后续已登陆状态的凭证。
长处:
- 每次申请将 token 放入 header 中,可防止 CSRF
- 本身无状态,可在服务间共享,服务端不保留 token 仍可校验其合法性。(不必在服务端保留 k -v)
应具备以下特点:
- 一个 Token 就是一些信息的汇合,蕴含如 username,phone-number,资源等信息;
- 可作为用户认证的凭据。因为 token 是被签名的,服务端可对 cookie 和 HTTP Authrorization Header 进行 Token 信息的查看,如果校验非法,可认为该申请是平安的
- Token 有肯定的有效期,保障安全性
- Token 在有效期内无效,无奈通过本身生效,除非通过放入 redis 辅助校验
过期策略:
Token 过期后应进行续签,而不是跳转到登陆画面,造成蹩脚的用户体验。Token 生效工夫过长会存在安全性隐患,过短会造成频繁的 refresh token。好的体验应该是在用户无感知的状况下进行 token 刷新。
- 服务端保留 token 状态,用户每次操作均刷新 token 有效期,可做到一段时间没有操作即登出,但这种计划对内存压力较大,每次操作都要拜访,失去了 token 可被验证的便捷性
- refresh token:用户登陆胜利后返回 token 及 refresh token,token 过期后通过 refresh token 续签 token,token 有效期短而 refresh token 有效期长,refresh token 生效后认为登出。可实现每次登陆保留登录状态肯定工夫。能够防止对内存的频繁读写
何时 refresh token:
- 前端建设定时工作每隔肯定工夫通过 refresh token 获取新 token
- 收到响应后,如果响应为 token 过期,通过 refresh token 获取新 token,再次发送申请,如果 refresh token 过期,阐明需从新登录