RBAC用户角色权限方案设计

1、权限表协甌 nMSH捉限标识 YfiKCJiftK2(50)用尸角色去缺用 QlD NUMBER 掛色ID HUMEER 扩展RBAC用户角色权限设计方案RBA（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色,每一个角色拥有若干权限。这样，就构造成“用户 -角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一 般者是多对多的关系。（如下图）用户表用户u财冠-用户名（30）角色是什么？可以理解为一定数量的权限的集合，权限的载体。例如：一个论坛系统，“超级管理员”、“版主”都是角色。版主可

2、管理版内的帖子、可管理版内的用户等，这些是权限。要给某个用户授予这些权限，不需要直接将权限授予用户，可将“版主”这个 角色赋予该用户。当用户的数量非常大时，要给系统每个用户逐一授权（授角色），是件非常烦琐的事情。这时，就需要给用户分组，每个用户组内有 多个用户。除了可给用户授权外，还可以给用户组授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在用 户组拥有的权限之和。（下图为用户组、用户与角色三者的关联关系）用戶组用，口油liN闍EER3用尸盥名称VkECHikF.2 (50)佥用戶组名称 mtER用戸辭与用户尖廣叢用尸组TD2 Jfl.lMBER 用尸LD2 Nl.BER

3、 用2蛆诺色关联族ffiPSgED IUWBER 角色JU MEER Fi； CI KEF EOLE用戶表甬色表圉尸卬im町囲用户容 VAaGJttBC50)诸 fein KUWEEH殖色塔 VMiCKJlfiS GO)USER用户角色关联表用戸口 mJMBER 坤色ID TODER (昭；弓I入用尸齟)-角色在应用系统中，权限表现成什么？对功能模块的操作，对上传文件的删改，菜单的访问，甚至页面上某个按钮、某个图片的可见性控 制，都可属于权限的范畴。有些权限设计，会把功能操作作为一类，而把文件、菜单、页面元素等作为另一类，这样构成“用户-权限-资源”的授权模型。而在做数据表建模时，可把功能操作

4、和资源统一管理，也就是都直接与权限表进行关联，这样可能更具便 捷性和易扩展性。（见下图）闌瓦 mra aw“屯e血硼口圍曲I峯油法菲勰曲iT7HaiiraMrjm_oj_hi k _眇盯 “urgziroT肋d耳塡耳(oe) swotm艙咚T1R餐誌CosjmmA咸辔聊瞬(D9硏弟OfM零护蛰迅燧犁北詢黑宦HoniAia峯總创頂nam ai4#x tj无取皿卫肛剧海 naawfui d瑋茎邀匹加业腮眦(nU询峯建栄率宴團莹呦御!?抽科帼CII甫華舉殖兴审举潮般辣怅划忑创曲(0功5TVHJ5WA悬規制笠(验理堂业 分知耳 麵脱请蔓聲挣耳0|顶0科丄圈驾辜些里鱼7H3Hil谟犬里蒐闕理亞uasiM

5、 to SSVIJIYA too刼阳毗OTMimoiWX 硼竜塗 舉空寅零尅兀宙逅峯甫运请留意权限表中有一列“权限类型”，我们根据它的取值来区分是哪一类权限，如“MEN”表示菜单的访问权限、“ OPERATION表示功能模块的操作权限、“ FILE”表示文件的修改权限、“ ELEMENT表示页面元素的可见性控制等。这样设计的好处有二。其一，不需要区分哪些是权限操作，哪些是资源，（实际上，有时候也不好区分，如菜单，把它理解为资源呢 还是功能模块权限呢？）。其二，方便扩展，当系统要对新的东西进行权限控制时， 我只需要建立一个新的关联表“权限 XX关联表”， 并确定这类权限的权限类型字符串。这里要注

6、意的是，权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。（文件、页面权限点、功能操作等同理）也就是每添加一个菜单，就得同时往这三个表中各插入一条记录。这样，可以不需要权限菜单关联表，让权限表与菜单表直接关联， 此时，须在权限表中新增一列用来保存菜单的 ID，权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。到这里，RBACX限模型的扩展模型的完整设计图如下:用尸爼用户细H硕倔k用PiS-g称AEC腼2書心父用尸组畜称NUMBER粟单表FK GUyGEOUFFK_G55DUF用户爼身用户矣朕轰用戸竝ng而丘云w云y角户ED2HTOER 用P爼储色芜联衷用户组ID NUM

7、BER 角色卫 WUMBEK FK GU E JF USERFK GR Iffif R0L用戶丟用户ID imi班F：uk用戶名 VARCHAB2130)NWER菜单ED 菜单3称 菜单斑 父菜单BFl血ER VAKCHAR2 VAKCHAK2 (60) KUHBBR虫面元索TTSijKD HI.IMBEK仙；克直元索褊珂VASCHW12 (50)文件表NMERkVARCHWC (5Q)文件ID究件若文件路径(Fn ；FK PN MEF ttEJTUFK FEELE惟 KTFK PFF FILE权限ID NUMBEB 黑重ID HUMBER 权眼页面丘素芙联轰 权卩肛dWEEK 頁面元素ID

8、WEER PIIB HUMBER 文件ID HWIEER FK_PW_EEFMRIVIIH避 E_EEFjRIVf附F-馨人血打店呦权諾恿Mbhwee 取隈类型 VARCMAJt2 C50FK_UEF.U5EHFK_UR_EDLEFK KP REF FRIHLEGE用户角邑羔联表用户LD NUMBER 兔色IU HUM EER 角色权限去联表felD SUNBIR 叔EID NI.INBZR (图：RE AC权限模型扩展5撫作編玛 拦截UKI肅嫌 皱操世tncitAREt5C) VARCHM2 CSO) VARCAK2 0) NUMBERFK P0 KEF JRIYILEEjFK FtJ KE

9、F 曲ERmClN X./椰賺作关联視枳FSir imim 操作ID MSER随着系统的日益庞大，为了方便管理，可引入角色组对角色进行分类管理，跟用户组不同，角色组不参与授权。例如：某电网系统的 权限管理模块中，角色就是挂在区局下，而区局在这里可当作角色组，它不参于权限分配。另外，为方便上面各主表自身的管理与查 找，可采用树型结构，如菜单树、功能树等，当然这些可不需要参于权限分配。以上，是从基本的RBAC莫型进行了扩展，具体的设计要根据项目业务的需要作调整。欢迎大家提出批评意见!这是我后面加的：具体实现的话，可通过表的关联查询得到， 根据用户ID查询到它拥有的角色， 再通过角色查询到它所拥有的权限。例如，查询某个用户所有授权的菜单:select m.* from menu m where exists (select Xfrom privilege_me nu pm, privilegee pwhere pm.privileged = p.privilegedand p.privilege_type = MENUand pm.me nu_id = m.me nu_idand exists(select Xfrom role_privilege rpwhere r