能力开放平台中的授权控制设计

今天与大家分享一次能力开放平台的授权设计过程,该设计已经成功实现并交予项目使用。软件设计的过程和炼丹的过程十分相似, 目的都是去伪存真, 把需要满足的所有场景展现在脑海中,不断找他们之间的关系,提炼抽象,最终得到最简单的模型,再用模型去满足所有场景的需求。

能力开放平台中所有的资源都是通过API对外提供服务的。我们主要针对API做授权控制。

我们罗列一下可能出现的控制场景:

接口访问控制。具有权限的用户可以访问该接口。接口入参参数授权。入参的格式是接口能力需要并定义的,所以只会对入参的值做权限限制,如某些人对入参中某个字段只能输入固定的值,入参参数满足某个条件时才具有该接口的访问权限。接口返回参数授权。出参中对访问者中某些字段做模糊,不可见的控制。同一个接口,不同的人可能处理逻辑都不一样,例如用户是省级管理者,可以查询全省的数据,如果是市级管理者,管理员,同一个组的人,服务创建者....,返回的结构一样,业务数据不一样。针对平台中数据元素,数据对象。对不同的用户可以拒绝访问,某些字段需要模糊化或不可见。还有一些特殊数据的控制。如菜单数据。

经过总结提炼,设计如下图

能力开放接口授权控制

1。服务控制

配置角色和接口名称的关系,角色有对应接口名称,就觉有该接口的访问权限。

提供根据用户ID,通过角色和配置信息判断是否具有访问该接口的权限。

配置角色和接口入参的关系,是一个表达式配置,根据上下文和入参做布尔表达式计算。

提供根据入参信息做布尔运算的接口,如果有配置信息,且运算结果为false,则不能访问该接口。

配置角色和返回参数的关系,是一个返回参数的结构,如果要模糊某个字段,需要在这个字段加在模糊函数,如果是隐藏某个字段,需要在这个字段加上删除函数。

提供真实出参和配置结构的转换接口,供把实际参数根据配置结构转换,并执行对应的函数。

用户访问某个接口验证通过后,会标记一下通过的方式:管理员/授权组/自有/服务授权,被访问的接口逻辑如果有对这些授权方式不同的逻辑的,需要接口内部自行实现。

2。数据控制

服务控制可以控制所有的接口访问限制,但是控制粒度太细,配置繁琐。常常会对访问的数据对象做限制,毕竟接口的一半功能是提供数据。在平台内维护数据字段字典和数据对象。

配置数据对象和角色的关系,角色拥有数据对象的关系,就可以访问这个数据对象。

配置数据对象中的某些字段和角色的关系,这些字段需要模糊处理或隐藏。

在数据操作层,根据角色和配置信息,对操作前检查,是否有访问对象的权限,对操作返回的数据结果做处理,哪些字段需要做模糊或删除处理。

2。特殊控制

某些特殊数据(没有在数据对象中的数据)的控制,如菜单结构数据。

异常信息,不同的角色获取到的异常信息不一样,如开发者获取到堆栈信息,操作员获取到系统错误信息,用户获取到联系信息。

用户的这些授权配置信息,在用户登录的时候一次性加载到集中式缓存中。

请求访问某个接口前会先判断用户通过校验的类型,主要可以分为:是否管理员、是否某个群授权、是否访问的是自己创建的服务、是否服务授权、是否特殊权限。校验通过后在上下文环境中打上标记。

总结:这一套授权控制考虑到了服务,入参,逻辑,出参,访问的数据,代码中的数据。自认是一套比较周全的控制模型,并可以从服务,数据,服务中的数据三个方向做功能扩展。除非出现了不在这三个方向的控制元素,那就无法控制了。

大家也帮忙审查一下是否有哪个场景不能控制到呢? 谢谢!

发表评论
留言与评论(共有 0 条评论)
   
验证码:

相关文章

推荐文章

'); })();