垂类账号权限平台的设计与实践

[魏小言]

目录

一、前言

二、账号登录服务

2.1 企业组织与账号模型

2.2 稳定高效可配置的统一登录服务

2.3 OAuth能力

三、权限服务

3.1 问题与思路

3.2 复杂的功能鉴权

3.3 灵活扩展的数据鉴权

3.4 高性能高可用的鉴权服务

四、总结

垂类账号权限平台的设计与实践
一、前言
百度 ToB 垂类账号权限平台（ 以下简称平台 ），是专注于为百度 ToB 垂类各产品线提供通用账号权限服务的基础平台，所提供的服务涵盖了租户管理、账号管理、单点登录、权限管控、账号安全、企业资质。业务方将账号、权限相关服务托管给平台后可以专注于自身的业务研发。目前已经接入了爱番番、爱采购、寻客宝、出海易一期产品线总计超过 1000万的企业账号，为各 ToB 垂类业务提供一站式账号与权限解决方案，以下是简化版的业务架构图：

△平台业务架构

以下列出了必要的名词解释，便于更好地理解本文内容：

名词

解释

客户

是指一个自然人或法人机构，团体，组织，公司企业等具有社会化属性的实体

租户

一个客户可以有多个组织，单个组织即是租户，是最小的计费主体，具备相关营业执照，行业，法人，公司地址等自然存在的属性信息

账号

租户下的最小资源隔离主体，通过账号登录业务系统

主账号

租户创建时，由系统自动生成的超级管理员账号

子账号

主账号创建的隶属于同一租户的账号，可以指定任意角色权限

用户

泛指账号，可能为主账号或者子账号

角色

是一种虚拟身份，关联一组权限，必须关联到某个用户身份才能使用

功能

某个业务功能，通常是多个接口地址组成，比如打开某个菜单页面、按钮是否可见等操作

资源

资源是用户与系统交互的对象实体的一种抽象

RBAC

Role Based Access Control，基于角色的访问权限控制模型

租户版本

SaaS产品的不同版本，比如基础版、专业版

BDRP

百度分布式 Redis，为各业务提供一站式的高性能缓存&KV存储解决方案

 关注我 code 杂坛，了解更多......

二、账号登录服务
2.1 企业组织与账号模型
平台支持一个客户在多个产品线注册多个租户，租户间的数据彼此隔离，每个租户默认创建一个主账号拥有最大的超级管理员权限，并生成具有管辖关系的租户组织结构树。主账号可以创建多个子账号，每个账号可以绑定多个第三方账号或者客户公司自己的账号体系（ 比如微信、手机号、苹果账号、UC、passport 等 ），超级管理员可以给每个账号分配不同的角色从而具备不同的功能权限，比如给客服人员分配客服一线角色具备 IM 沟通权限。

△企业组织与账号模型

2.2 稳定高效可配置的统一登录服务
ToB 垂类的业务场景不但需要支持 Saas 类业务，也要支持大客户私有化部署的业务，在设计的目标上，平台的账户登录服务需要给各类业务提供一个安全、稳定、高效、可配置的统一登录服务。

△登录服务架构图

作为企业应用的登录服务，为了保证企业用户的安全性，在流程上的设计上增加了很多安全的策略，所以总体的登录流程会较复杂：

首先以账号密码登录为例，当用户进入爱番番的页面的时候，系统页面进行初始化，此时给当前的页面生成一套独有的加密信息和时长。这里加密信息会用于后续用户填写账号、密码等信息的传输过程当中的加密；时长是当前页面的时长，如果用户在当前页面静止的时间超过系统规定的时间，那么页面信息将会失效，系统会重新加载页面。当用户填写账号、密码、验证码等信息的时候，传输给系统一串加密信息，系统会在页面最开始加密生成的加密信息当中找到密钥，并进行解密，等完成基本的账号密码信息的校验后，会经过一系列的安全策略，比如非常用地登录、常用设备检查、手机验证检查等等。安全策略通过后会生成临时验证信息返回给前端，前端在进行校验的时候，系统会将临时的登录信息替换成真实的登录信息，从而系统完成了一次登录行为。

△账号密码详细流程图

那么作为 saas 服务的统一业务基础，我们需要在登录服务上解决几个问题：

如何支持登录服务可配置化？可配置化能力可以支持不同的企业在私有化部署的场景可以按照企业自身的业务来定制登录流程，也可以支持爱番番 saas 服务接入不同的产品线的定制化需求。

如何支持多产品线应用接入并支持单点登录？

如何保障账号登录安全？登录服务的核心就是保证登录功能的安全性，作为爱番番、爱采购等系统的一级服务，防止系统被恶意入侵，登录流程的安全性就变得非常的重要。

2.2.1 配置扩展能力

一个复杂的问题通常是有多个小问题组合起来，而处理一个复杂问题也会涉及到多个不同的处理步骤，只需要采用分而治之的方式，将复杂的处理逻辑拆分出不同的小的步骤，这样可以将问题简单化。所以核心的处理思路也是将登录流程不同的处理步骤拆分出来，将步骤对应行为和操作。这样就可以得到多个不同的原子行为，而每一种行为对应不同的原子操作。

2.2.1.1 模型抽象

基于该思想可以抽象出一套模型，如下图，爱番番账号体系是可以支持多产品线的接入的，一个产品线归属多个账号。P 代表产品线，U 表示账号，E 代表登录服务的一些原子事件，C 代表登录相关的配置，S 代表登录相关的安全策略。一个产品线下可以组装不同的登录流程需要的原子事件，所以 P 和 E 的关系是一对多的情况。产品线 P 也可以有不同的配置，比如登录态时长、是否支持多端同时登录、登录端的个数等等配置。无论是产品线或者账号都会有一系列的安全策略的配置，当然这些安全策略可以是账号粒度也可以产品线粒度，比如对于一些黑产账号、异常登录行为账号的封禁策略，判断账号是否在常用地登录的提示策略等等。

△配置扩展能力图1

通过将登录过程的步骤进行拆分，由不同产品线进行组织步骤可以实现企业的一些自定义的需求，但是如何支持不同的登录方式进行可配置操作？登录服务需要支持不同的登录方式，如密保手机登录、扫码登录、第三方登录等等主流通用的登录方式，在设计可配置流程的时候需要确保设计的通用性，将不同的登录方式的登录流程也能套用一套模型当中。抽象模型 M，表示登录方式，M 也是由不同的事件组成，而产品线P是可以自定义自己的产品需要哪些登录方式的，通过前端登录组件进行展示。当然为了考虑到安全性等方面的可配置，也设置了黑名单、白名单。黑名单可以基于账号级别的一些封禁，也可以基于异常 ip、手机号等进行封禁，而白名单往往和安全策略相关，比如一些跨域请求、跳转请求等等。下图就是基于上述一些考虑丰富后的登录服务配置扩展能力抽象模型。

△配置扩展能力图2

2.2.1.2 统一登录流程

基于设计的配置扩展的能力，可以将最开始的账号密码登录流程抽象成如下的登录可配置流程图，首先采用通用的加解密服务对请求的参数进行加密处理，然后各类的原子事件和对应的原子事件处理器都注册到中央处理器当中，通过中央处理器来进行组装流程，中央处理器会通过产品线和登录方式来查询数据库配置的事件编号顺序，然后逐步触发执行触发。

△统一登录流程图

2.2.2 单点登录

2.2.2.1 流程介绍

单点登录，一般应用于多个应用系统中，用户只需要登录一次就可以访问互相信任的应用系统。比如访问 http://a.baidu.com , 当登录之后，再次访问 http://b.baidu.com、http://a.aifanfan.com 都是可以免登录进行系统当中，用户只需一次登录，各个系统即可感知该用户已经登录。

△单点登录对比图

基于上述对于单点登录的说明，可以想到只需要不同端认可一份登录认证凭据就可以实现，由于 http 是无状态的，自然可以想到 cookie 用于传递不同端的用户信息，但是由于 cookie 和域是强相关性，且基于浏览器有丢失的问题，所有在不同的端互通登录态使用 cookie 存在两个问题：一是跨域问题；二是 cookie 丢失问题。平台基于 CAS 协议设计实现一整套基于多端的单点登录流程，不但可以基于浏览器解决 cookie 问题，并且支持 native 各应用之间登录互通。

如下图是平台账号单点登录的主要流程图，在系统 A 使用 ToB 账号登录的时候，登录成功后，认证中心会生成一个临时认证信息 Stoken，并且会写入认证中心的域名 www.b.com 下 cookie 当中 Ptoken，当系统成功跳转系统当中，业务A服务端网关集成登录校验 SDK，由登录校验 SDK 将临时认证信息 Stoken 换取系统 A 的真实稳定的登录态，生成只属于系统 A 的登录校验 Atoken；当系统 A 跳转到系统 B 的时候，系统 B 服务端登录态校验发现当前域名下并没有登录信息，会执行 302 跳转到认证中心，由认证中心查找域名 www.b.com 下 cookie 当中Ptoken，通过认证后，会给系统B的请求接口返回临时 Stoken，由登录校验 SDK将临时认证信息 Stoken 换取系统B的真实稳定的登录态 Btoken。所以不同系统去认证信息的时候只需要关心系统本身域名存放的信息即可，如果登录校验失败或者 cookie 丢失的场景，会跳转到认证中心再次进行校验。

△单点登录流程

2.2.2.2 认证逻辑

在流程介绍当中可以了解到单点登录当中设计了三种票据 Stoken、Ptoken、Rtoken ：

Stoken : 服务临时 token，由认证中心去颁布；

Ptoken : 存放在认证中心服务端，会请求通过 Cookie 或者 Header 的 Key 值找到相对于的 Ptoken，从而拿到用户信息；

Rtoken : 业务方专属的 token，用于当前系统的登录态校验。

生成Stoken

临时 Stoken 生成的时机有两种，一种是不同系统互相跳转的时候生成，一种就是登录的时候生成。不管哪种场景都是由认证中心去颁布，临时 Stoken 对应服务端存储的数据结构需要包含当前登录的账户信息、校验信息、客户端信息、加密信息。在设计上是一种 Hash 的结构方式，临时 Stoken 存储各类的信息保持 key-value 的方式，这样读取、存储都清晰方便。当业务系统设置登录完成跳转后的地址是 http://a.baidu.con/index  ，那么生成临时 Stoken 后，登录服务 SDK 会将 Stoken 追加到跳转地址上，变成  http://a.baidu.con/index?st=xxxxx ,由于临时 Stoken 暴露在 url 上，为了保证安全性，临时 Stoken 的有效期设置 30s 以内，如果 30s 当中，临时 token 没有被业务请求进行认证，则直接进行销毁。

Stoken换取Rtoken

当业务 A 登录后，业务请求经过登录 SDK 校验的时候，会拿到请求参数上的Stoken，通过解密到真实存储的 Key，拿到当前登录的账户信息、校验信息、客户端信息、加密信息，生成稳定 Rtoken，将 Stoken 的信息复制到 Rtoken，并通过产品线的配置设置登录态时间。这一步就是临时 Stoken 换取真实登录态Rtoken。

校验登录态过程

△登录态校验示意图

2.2.3 登录安全性保障

2.2.3.1 分阶段session控制

通过之前的登录流程可配置、单点登录流程的介绍，在实际处理过程当中，将服务器的 session 划分成三个部分，分别是登录时期的 session、临时 session、登录态 session 。登录时期的 session 控制总体登录流程的时间，防止恶意狂刷，这种的 session 时长要设置分钟级别，如果 session 过期，需要前端登录 SDK 重新加载初始化页面信息，重新开始登录流程；临时 session 就是为了单点登录设计，这种 session 时长设置秒级别；真实登录态 session 为用户最终的登录session，存在真实的登录 Token 信息，通过不断的交互 session 来保证登录流程的安全性。如下是账号密码登录划分图。

△分阶段session划分

2.2.3.2 敏感信息加解密

加解密过程在登录流程比较重要，也是为了安全性，将具体的加密算法进行替换。这里面使用对称加密算法 A 、非对称算法 B，账号密码加密算法 C、D 等。

△加解密流程图

加解密过程如下：

首先通过加密算法A生成一对秘钥对，将公钥给端上使用，端上随机数 Random 结合公钥算法 A 加密当前随机数 Random 传给登录服务。

首先 Random 将解密出来，然后生成新的密钥对，然后将私钥，公钥存放 session 里面，并返回算法 B 加密后的公钥，这个公钥的 salt 是解出来的原始的 Random 参数。

端上算法 B 解密后出真实的公钥后。将密码算法 A 加密。

密码校验的时候，会在 session 里面取之前存的私钥，解出原始密码，再通过算法 C、D 加密后和数据库比对。

2.2.3.3 其他安全举措

cookie属性

Secure：安全性，指定 Cookie 是否只能通过 https 协议访问，一般的 Cookie 使用 HTTP 协议即可访问，如果设置了 Secure（没有值），则只有当使用 https协议连接时 cookie 才可以被页面访问。

HttpOnly：如果在 Cookie 中设置了 " HttpOnly " 属性，那么通过程序 ( JS 脚本、Apple t等 ) 将无法读取到 Cookie 信息，防止 xss 攻击。

时长：设置有效期，建议设置时长不宜过大。

请求校验

域请求限制：登录相关的接口支持跨域的场景，但是需要校验请求头 origin 属性，设置白名单，只有在登录认证中心配置的来源 origin 才可以放行；对一些执行 302 跳转的请求，同样设置白名单的控制跳转请求。

频次：登录相关的请求会根据当前的 IP、浏览器唯一 ID、客户端设备 ID 等信息设置时间范围内频率的限制，如果超过阈值，会进行频次报警，也会对指定的 IP、设备、账号进行及时的封禁。

验证码

验证码是非常有必要的，而验证码的目的就是区分正常人和机器的操作。验证码的作用在于区分人和机器，防止被暴力破解，提高破解密码的难度。只是不同阶段表现形式不同，未来的趋势是更加智能无感知，用户体验更好。登录服务支持图片验证码、人机交互滑动验证码、手机验证码。业务方可以根据安全要求不同接入不同的验证码的方式。

2.3 OAuth能力
2.3.1 OAuth介绍
ToB 多租户账号服务支持客户相关需求，有时候会和外部企业进行合作，需要保证客户体验的一致性，打通外部平台和账号系统的账号授权关系，保证登录爱番番系统的客户可以免登录到外部系统。因此需要形成一套完善的授权体系。OAuth 2.0 是目前最流行的授权机制，用来授权第三方应用,获取用户数据。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（ token ），用来代替密码，供第三方应用使用。

2.3.2 授权流程
在用户授权登录已接入 OAuth2.0 的第三方应用后，第三方可以获取到用户的接口调用凭证（ access_token ），通过 access_token 可以进行对外提供的OpenApi 接口进行调用，从而可实现获取爱番番账号用户基本开放信息和帮助用户实现基础开放功能等。目前平台 Oauth 能力支持 authorization_code 模式，该模式整体流程为：

第三方发起授权登录请求，当查询相关应用注册到授权中心的时候，如果用户没有在账号系统进行登录，会默认链接到提供的统一授权登录页，登录完成后会拉起应用或重定向到第三方网站，并且带上授权临时票据 code 参数；

通过 code 参数加上 AppID 和 AppSecret 等，通过 API换取access_token；

通过 access_token 进行接口调用，获取用户基本数据资源或帮助用户实现基本操作。

△OAuth时序图

三、权限服务
作为 ToB SAAS 产品的基础权限服务，服务于多个产品线，需要为来自各行各业的客户解决复杂多变的权限管控需求，提供包含功能权限和数据权限管控的能力。

 关注我 code 杂坛，了解更多......
————————————————
版权声明：本文为CSDN博主「魏小言」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_34417408/article/details/124122020