RBAC(Role-Based Access Control ,基于角色的访问控制)模型是后台产品设计中常用模型。本文属于事后总结,希望对各位读者有一定的帮助,当然也有一定的局限性,欢迎留下你的评论,相互探讨。
最近西蒙折腾业务管理后台的从0到1,接到任务那刻,就开始投入资料的搜集和汇总工作。但是很多网上的资料都是基于技术层面的解释,但是很少有通俗易懂的说明,工作就开始了卡顿。
搜索出来的资料,很多都是这样的图表,后续咨询了很多伙伴,感谢他们的建议和分享,终于顺利完成了框架的梳理。撰写此文属于后续的思考沉淀,希望对各位读者有一定的帮助,当然本文也有一定的局限性,欢迎留下你的评论,相互探讨。
当框架梳理完毕的那刻,头脑中闪现的就是《结网》的一句话:不需要再发明轮子。
一、RBAC模型无处不在,不需要再次发明轮子,在于归类提炼
一开始搜索RBAC模型,很多都是偏技术类的说明,如用户表、角色表、用户角色关联表、权限表、权限角色表之类,没有一个概要(通俗)的说明。梳理完毕以后,发现其实RBAC模型是无处不在。
举几个例子和大家分享一下:
会员打折,基于会员卡,商品结账时,可以享受较低的支付价格。
公司的门禁卡,是分发给公司员工,只有是公司员工的身份(角色),才能领取门禁卡,才能使用打卡出入(权限),同样基于员工的角色,所以要上下班考勤打卡(权限限制)。如果离开了公司,那么不再是员工(角色),所以无法出入公司大门,也无需上下班考勤打卡。
公司是有组织架构,不同的岗位,有不同的管理权限,财务总监可以管理公司账户,人事总监管理公司人事,与之对应的是财务部成员和人事各自有不同的权限
当我们打开微博/微信,发表内容的时候,是输出者,看别人内容的时候,是浏览者,输出评论的时候,是评论者,也是基于不同的动作,触发不同的权限。如内容输出者享受的权限就是可以看到多少人点击,查看评论,回复评论,点赞数等
当我们打开游戏的时候,游戏也是有角色权限约束,游戏里面的角色,达到N级,可以解锁对应的技能,解锁符文镶嵌位,解锁副本,解锁其他游戏场景入口
RBAC模型无处不在,所以不需要再次发明轮子,在于归类提炼,融合贯通。
二、RBAC核心是用户-角色-权限的模型
RBAC核心是用户-角色-权限模型,但是这个模型也是一步步衍化而来,早期的是用户-权限模型。
这个模型的理念,是直接基于用户勾选权限,实现用户的赋权,但是这个模型有一个硬伤,就是无法复用,效率太低。无法批量套用,需要依次处理
以一个千人论坛为例:需要为一千个用户,手动配置权限,实现超管,超版,版主等用户的赋权。
想想为1千个用户依次配备相关权限。
现在的论坛,贴吧,已经可以实现数十万,数百万级的用户支撑,显然简单的用户-权限角色是不切实际的,事实上他们用的是改良后的用户-角色-权限的模型,也就是本次要分享的RBAC模型。
用户原本没有权限,基于角色对应的权限,获得对应的权限,用户变更角色,既可以获得对应的权限
现在还混贴吧和论坛的老鸟,应该知道在自己熟悉的板块,和自己未去过的板块,积分,头衔是不一样的,比较常见的是自己板块/贴吧,去到其他不熟悉的地方,也得从0开始熬,除非是获得对方超版调整为嘉宾,小吧主之类,那么就直接获得相关权限。这里面已经是一个用户-角色-权限的模型,这也是非常成熟的模型,所以西蒙一开始说的就是,不需要再发明轮子。
事实上,论坛的后台可以把各大板块分别设置模块,从后台层面,已经把可操作性,可见性进行区分,比方说普通用户是无法可见特殊板块,因为特殊板块可以单独设置为个别等级才可见(勾选权限),实现模块可视化的隔离。
回到论坛的角色配置,可以单独为用户的不同板块分别配置角色,用户直接基于角色获得对应的权限,用户完整的权限取全部权限的并集。基础角色就是注册用户,享受默认对应的权限即可。
如上面的图所示,甲在论坛的权限汇总之后如下:
从完整的RBAC模型会是这样的梳理实现。为了让大家更好理解模型结构,下面以人人都是产品经理的角色与权限进行详细的说明
三、人人都是产品经理角色与权限的概述
人人都是产品经理的主页面,点击各大板块的入口(红框部分),对于首页各类内容进行分类,
页面分类了很多的内容,但是涉及的板块并不多,基于板块再次细化后形成信息架构图,核心的内容为为文章、起点学院、天天问、秒聘网,个人信息。
西蒙实测对应的角色,尝试逆推相关的权限,梳理如下:
角色以及对应的权限
普通未登录用户(访客)
未登录的情况下,基于访客的身份,获得访客的权限:搜索文章,浏览文章,浏览天天问,浏览起点学院的内容,但是更深一级的操作,如文章评论,回答问题,查看视频均会弹出登录的提示
登录用户(核心角色)
用户基于手机,用户名和邮箱,微信登录之后,将获取到之前存储的账户信息,同时角色替换为已登录的用户,则权限取未登录用户和已登录用户的并集。用户登录后除了访客的之前的搜索文章,浏览文章,浏览天天问,浏览起点学院的内容外,附加了作者,评论者,天天问板块的角色,获取对应的消息提醒。
其他角色
起点学院的年费会员,红钻会员,绿钻会员以及天天问的角色,属于其他角色类型的一种,用户触发则激活该角色的权限,不触发则视为标准的用户权限。
具体为:只有在触发起点学院课程的时候,进行浏览权时判定,其中年费会员>红钻会员>绿钻会员,若课程为绿钻用户可访问时,则普通用户不可访问,返回错误。绿钻及绿钻以上的会员可以访问该视频。
同理:用户没有使用过天天问,或仅仅是浏览,没触发其他提问,回复问题等操作,则没有触发相关信息的推送提醒
运营管理角色
基于相同的逻辑,运营团队也是依据对应的角色,获取对应的权限,对于用户,内容进行管理。比如CECI的账户被勾选为天天问的管理员,则CECI可以管理天天问板块,当CECI被勾选文章的管理员,则CECI可以被临时当苦力,去加快文章的审核进度。
同理总编大人和曹大为超管角色,可以同时管理多个模块,以及对于员工的角色调整、
四、写在后面的思考
事实上,RBAC模型在很多场景都会运用上,希望本科普小文对大家有所帮助。
RBAC也可以复杂多样化,比方说游戏里面的帮派,活动,门派,跑商,任务以及对抗,都是基于角色来触发对应的内容,加入门派(门派角色),获得门派的技能树(门派权限),加入帮派(门派角色),获得对应的帮派任务和帮派福利。
RBAC的复杂程度是基于后台角色的复杂性,所以做好适当的预留空间,很重要。同样,对于RBAC模型进行改造的时候,对于整个用户-角色-权限的探索复盘也很重要,
西蒙的RBAC模型的分享到这里就差不多了,在这里感谢RAIN,小菜鸟,老王,以及很多热心伙伴的分享和建议。
*请认真填写需求信息,我们会在24小时内与您取得联系。