侵权投诉
订阅
纠错
加入自媒体

应用基础框架之权限控制

2019-05-10 15:30
EAWorld
关注

引言:

权限控制在每个应用中都必不可少,相似却又总不尽相同。有没有一种比较通用的设计甚至框架,可以让我们不用每次都去重复造这个轮子呢?本文主要是向大家介绍下我们的应用基础框架coframe,以及在权限控制方面的一些设计与实践。

目录:

一、应用基础框架简介

二、应用权限模型设计

三、应用权限控制

一、应用基础框架简介

相信很多同学都有过这样的经历,刚做完一个项目,开始一个新项目的时候,发现基础能力又要重新开发一遍,用户,登陆,菜单,机构人员,权限管理等等。重复的工作枯燥而没有价值,却不得不做。能否来个什么框架,可以直接提供这些开箱即用的基础能力?

回答当然是有,我们这里把这种包含了应用基础能力与通用业务模块的框架,称之为应用基础框架。它就像一个半成品的车架,已经有了基本的架子,轮子,发动机,方向盘等,基本上已经可以跑了。但是车子更多的其它能力,还等待人后续去完善。

完整的应用基础框架,应当包括应用后端基础框架与前端展现基础框架(包括 web 或移动)。这样两者配合使用,才能直接为应用提供开箱即用的业务能力。

不论前后端,我们认为框架可以分为以下四层:

基础依赖层:基本上定义的框架的技术栈,采用什么语言,什么框架,依赖哪些基础库或组件等;

基础能力层:定义的是基础能力,后端包括对异常的定义,国际化的处理,ORM模型的抽像等等,前端则是对菜单,路由,通信等的框架化封装,通用基础组件的抽取等;

通用业务层:实现通用的一些业务能力,如用户管理,登入登出,权限控制等等;

用户业务层:这一层交由用户去扩展,实现各自已的业务能力;

Coframe就是我们构建的这样一套应用基础框架。它的后端框架,基于 spring boot + spring security + jpa, 前端基于 vue + iview。

Coframe应用基础框架能力图谱

coframe提供的基础能力有:

组织机构:机构树管理,机构管理,岗位管理,工作组管理,员工管理;

用户认证:用户管理,本地认证,单点登陆(需与 iam 集成);

权限管理:权限模板管理,角色模板管理,角色管理,资源组管理,菜单管理,功能管理;

数据字典:字典类型管理,字典项管理,字典国际化,导入导出;

日志管理:统一日志接口,日志全索。

所有这些能力开箱即用。

下面我们重点分享一下关于应用权限方面我们的一些设计与实践。

二、应用权限模型设计

首先,我们要了解一下,什么是权限。我们认为,权限就是用户对某些资源的控制能力。所以,模型上我们就有了一个抽像的资源概念。

资源按类型具化,可能是用户在门户上可见的菜单,或者是页面上可见可点击的某些按钮,或者用户在应用后端可以调用的某个接口等。

用户通过角色,与这些资源建立了关联,我们才能在系统中通过用户找到这些资源,然后对它进行控制。

因此,用户,角色,资源的关系,就是一个用户可分配多个角色,一个角色,可以关联多个资源。如下图所示:

为了方便角色进行资源授权的管理,我们又提出了几个服务于它们的概念:角色模板,权限模板,资源组。

资源组,顾名思义,就是资源的分组。它是一个树状模型,目前主要设计使用了三层。顶层的代表着某一块的资源总集,比如某个子系统的资源总集。

权限模板,它通过关联多个顶层的资源组,可以代表着某个范围内的可授权资源总集。角色模板关联着权限模板,从它的这个资源集合中挑出了一部分。

角色则是在创建的时候,复制模板的这些资源授权。但它后续可以修改,整个可授权资源仍为权限模板代表的总集。

资源的授权如上图所示。顶层的资源组代表着某一块的资源总集,第二层则代表不同的资源类型,如菜单,功能,环境等。第三层代表着模块,比如机构管理模块的菜单。第三层的资源组之下,才关联具体的资源。对角色或者角色模板进行资源授权配置时,只需要找到对应的资源类型与模块,再找到相应的资源,点击是否勾选即可完成授权,非常地直观。

用户是如何与资源关联起来的呢?如下图,这里我们假设了一个示例。

某应用集成了 coframe,其下又分了三个子系统。为了方便资源的管理,我们为每个子系统设置了一个顶层的资源组,然后为它配置了下层资源组与资源。然后,我们设置了两个权限模板,其中一个负责 coframe 与子系统一的资源,另一个则负责三个子系统的资源。基于两个权限模板,我们分别创建了角色一与角色二。三个用户中,用户一分配了角色一,用户二分配了角色一与二,用户三分配了角色二。用户一可分配 coframe 与子系统一中的资源,用户二可分配所有资源,用户三则只能分配三个子系统的资源。这样,资源的组合与隔离,会变得相当方便与直观。

三、应用权限控制

我们认为,应用的权限控制可以分为如下四类:

1.菜单:用户在应用门户中可见哪些菜单可以通过权限控制;

2.按钮/链接:用户在门户页面中,哪些按钮可见可操作,可通过权限控制;

3.接口调用:不通过门户,直接通过客户端进行接口调用,接口是否允许调用可以通过权限控制;

4.数据:用户是否可见某些数据,能否操作可以通过权限控制。

菜单控制

菜单的控制其实比较简单。用户登陆成功后,前端会再来取一次用户的菜单项。后端服务根据用户分配的角色中,包含的菜单资源,在门户中组织出他所持有的菜单树。

但是菜单的组织过程,却也可以有一些不同。这里我们一种称为动态结构,另一种为静态结构。

动态结构首先要求菜单本身为树状结构,且菜单对应的页面(vue 中叫路由),图标等也记录在菜单中。整个菜单的层次结构,由菜单本身的树状结构表现。这种结构的好处是菜单配置非常灵活,菜单可以完全通过页面操作进行定制。这种结构适合经常需要动态变更的系统,且菜单配置人员对前端要非常地熟悉。

另一种静态菜单结构,则菜单只需要一个平铺关系即可。菜单的层级,顺序,路由,图标等由前端定义,后端只定义用户可以用到哪些菜单。缺点是菜单定制不够灵活,但优点也很明显,非常便于前端开发,前后端分工更明确。

按钮/链接控制

有些系统中,会将按钮的权限与后端功能的权限分开设计为两个模型,但 coframe 中这两个合为一个叫做功能的模型。功能有唯一编码,这个编码在按钮上可控制按钮的显示,在方法上可以控制方法能否调用。

按钮的控制也比较简单,特别是组件化的前端开发框架中。只需要为所有的按钮组件添加一个权限码定义,在页面渲染时,判断一下当前用户是否拥有这个权限码,有则显示此按钮,没有则将按钮从父组件中删除。

接口调用控制

在接口调用控制上,我们考虑过使用现成的一些控制方法,如 spring method security。但是它只能控制到角色级,虽然可以规则匹配,但仍然不够灵活。所以,我们基于功能编码,自行设计了一套。

它的基本原理是,我们使用 annotation,在每个需要控制的方法,添加了调用此方法需要的功能编码。方法被调用时,我们通过 aspect 对方法进行拦截,取得调用它所要求的功能码。然后我们在当前用户所拥有所有的功能码(在用户登陆时已查询出来放在 context 中了)中进行对比,如果存在就允许方法调用,否则抛出无权调用的异常。

鉴于有些需要控制的方法可能在父类中,所以我们定义了两个 annotation,一个定义在类上,可以配置父类上需要控制的方法。另一个定义在方法上,配置方法控制的权限码。查询方法调用所需权限码时,优先在方法上找到,找不到再到类上去查找。

为了方便集成的应用实现接口调用控制,我们定义了一个抽象的方法权限切片处理类,封装了对方法调用的拦截过程。应用只需要继承这个类,配置需要拦截哪些接口即可。

数据权限控制

数据权限,我们认为数据权限 = 数据可见控制 + 数据操作控制。

而数据操作控制,通过按钮控制与接口调用控制组合,基本上可达到想要的效果。

那数据可见如何控制呢?我们归纳为两种:成员法与资源授权法。

成员法,就是用户如果为某个领域的成员,则他就可以看到这个领域,以及这个领域中的资源。如何实现呢?简单一点的办法,就是用户的某个角色,属于这个领域,就可以认为这个用户是这个领域的成员。像租户隔离,devops 中的项目隔离,其实就是用的这种方法。

资源授权法,将某个精确的资源授权角色,或者直接授予用户。成员法实现数据可见控制有一个问题,就是粗度太大,不好实现更精确更细粒度的资源可见控制。要实现更细粒度的,可以使用资源授权法。但粒度细也就代表着管理复杂,孰好孰坏需要权衡后去使用。

精选提问:

问1:请问下数据的可见性控制,是如果做到可配置的?不同的数据,定义的特征和维度都不一样。  

答:数据可见性分通过成员授权与资源授权控制。成员授权,比如项目成员,首先是角色有归属,有些角色是只属于这个项目的,如项目经理,开发人员等。为用户分配这些角色,用户即成为了此项目的成员,对项目及项目下的资源可见。资源授权,则是直接将某些特定资源绑定至角色之上,用户配置了此角色,此用户对此资源可见。资源一般用类型与 ID 两个属性标识。

问2:资源授权法就是针对每条数据进行授权吗?

答:资源授权,是直接将某些特定资源绑定至角色之上,用户配置了此角色,此用户对此资源可见。资源一般用类型与 ID 两个属性标识。

问3:请问下生成权限的操作是怎么抽象设计的?比如应用,菜单,页面,api,文件,用户,角色,生成这些资源的权限是如何做的设计?

答:抽像模型上,我们主要为三个:PARTY, AUTH, RESOURCE.  party 为参与者,用户,人员,组织,机构,工作组,岗位等都可以归为此类。 AUTH 为资源载体,角色,角色模板可归为此类。资源则包括菜单,功能,应用,api,页面等也都可以归为此类。参与者关联多个资源载体,资源载体关联多个资源,实现资源与参与者的多对多关联。

问4:数据的权限怎么控制,比如微服务中一个A服务,里面又个a资源,里面如何根据数据标识来进行数据权限控制?

答:目前coframe 中的资源,主要通过类型与id (或者编码)来标识。如果维度较多,可以通过添加属性,或者为 id 或编码定制命名规则来扩充。

问5:数据权限里面的继承问题,比如CMDB里面的服务和节点,拥有服务,就拥有了节点的权限,这种该如何控制?

答:这种有继承问题的权限,建议使用成员授权来控制。我们可以为服务配置专用的角色,用户绑定此角色成为服务的管理成员。节点上冗余服务的标识,查询时进行成员关联判断。

问6:数据权限控制里面的,如何让数据对用户不可见,比如a用户,如果没有b资源的权限,就看不到b的权限。

答:原理其实就是在查询数据时,可以根据条件对它进行过滤。成员授权,与资源授权,就是为他们添加关联条件。一个间接,一个更直接。

推荐阅读

普元容器云关键设计和实践之路

容器时代的DevOps部署

有状态容器实践:k8s集成ceph分布式存储

关于作者:秦双春,现任普元云计算架构师。曾在PDM,云计算,数据备份,移动互联相关领域公司工作,十年以上IT工作经验。曾为科企桌面虚拟化产品的核心工程师,爱数容灾备份云柜系统设计师,万达信息的食安管理与追溯平台开发经理。国内IAAS云计算的早期实践者,容器技术专家。

声明: 本文由入驻维科号的作者撰写,观点仅代表作者本人,不代表OFweek立场。如有侵权或其他问题,请联系举报。

发表评论

0条评论,0人参与

请输入评论内容...

请输入评论/评论长度6~500个字

您提交的评论过于频繁,请输入验证码继续

暂无评论

暂无评论

文章纠错
x
*文字标题:
*纠错内容:
联系邮箱:
*验 证 码:

粤公网安备 44030502002758号