笨笨的熊窝
度尽劫波兄弟在,相逢一笑泯恩仇
posts - 9,  comments - 110,  trackbacks - 4
        不好意思,本来还没写完,只想存成草稿的,但点错了按钮,结果就发布出去了。现在第一篇写完了,这里说明一下,请大家谅解。
        引言:本来园子里已经有不少RBAC方面的文章了,而且自己的这个系统也参考了其中一些朋友的思想和创意,考虑是不是还有发表的必要。但感觉虽然是同样的东西,由于每个人的出发点与目标都不相同,所以做出来的东西也不会是一样的。而且有些东西,我现在只是做出了架构设计,具体实现起来会不会很合适,也不太清楚。有园子里的弟兄们给提提建议,也是一件好事。是不是发在首页,也考虑了一下,感觉这篇文章,抛开质量不说,起码从字数上会对得起大家。      

        正文部分

        关于RBAC的基本理论,这里就不再多说了。
        我是去年才接触RBAC这个概念的,许多东西了解的并不透彻,而且由于几年前就已经熟练使用Windows活动目录的权限管理系统了,因此一些理念和正宗RBAC观念会有一些出入,但应该不会对RBAC的主旨产生太大的影响。如果您觉得我加入的一些东西是多余的,或者感觉不习惯,欢迎提出看法,我会根据情况进行改进,谢谢。
        其实开始并没有编写RBAC的想法,但是使用了微软的membership后,感觉很不顺手,兼容性、易用性、复用度等方面也感觉不适合自己。正好手上几个项目都涉及到了较为复杂的用户权限管理功能,因此年初决定用几个月的时间来专门做一下这个项目,即通过这个过程进行学习,也减轻一下以后的工作量。
        因此,我写这篇文章也不是为了建立一个RBAC的范本,从理论上来供大家研讨,而是一切从实际出发,把我制作这个项目中的想法随着项目的进度写出来,在这个过程中探讨遇到的理论与技术点。
         
        废话说得太多了,转入正题      
        要做RBAC,首先需要确定需求。开始是根据几个项目来考虑它们的共同点,看涉及到用户管理、权限验证的部分,那些是几个项目都需要实现的,哪些是某个项目所特有的,慢慢确立了RBAC的需求,决定了它要实现什么功能。
        开始时,只想将项目从数据库建模开始,往上做到BLL这一层,然后其它项目可以使用此BLL,处理RBAC方面的工作,就相当于把几个项目的RBAC部分共享一样。
        后来感觉如果只做到这一层的话,以后复用的话,工作量还是会很大。所以决定将后台管理部分的UI层也做出来。这样就相当于几个项目连界面部分也可以共享了。
        然而在实际过程中,觉得即使做出了后台管理的UI。其它项目使用这个模块也会比较费事。而且这种模式,项目对RBAC的调用与调用项目内模块没什么区别。用户在使用RBAC项目时还是需要了解其内部的一些操作方法,耦合度太高,没有实现封装。
        后来有了进一步的想法,能不能将其做成一个框架。虽然水平有限,说框架有些大,而且也不见得能做完美,但目标还是可以定得高一点么。
        既然想做成框架,那就不是提供一个数据库模型,并完成相关的代码就了事的。我的想法就是,能够让用户在用脚本建立建立数据库,复制UI界面文件到项目文件夹,并引用dll后,无需再进行其它的配置工作,就能直接使用这套框架。用户自己编程进行RBAC操作时,只要一两个类就可以完成所有工作,对用户隐藏所有细节。
        基于这种想法,我开始进行项目的建设,现在已经建立了下面几部分:
        (1)BLL:业务逻辑层。
        用于处理业务逻辑相关的工作,此层内容仅对RBAC项目内的成员开发,不提供对外调用。
        (2)ClassFactory:类工厂。
        当前仅支持数据访问层对象的创建。以后视需要增加新的工厂。
        (3)Demo for WinForm:C/S模式界面模板
        提供Windows程序的界面文件与操作代码,如果不想自己设计界面,可以直接使用此现成的界面文件。
        (4)Demo for WebForm:B/S模式界面模板
        提供Web项目的界面文件与操作代码。如果不想自己设计Web界面,可以直接使用此界面。否则只要制作新的CSS文件,替换原有css文件,即可实现自己的界面。
        (5)IDAL:数据库访问层接口定义
        没什么好说的
        (6)Model:实体类
        同样
        (7)OracleDAL:Oracle 数据库访问层
        支持Oracle数据库,这个准备先放一放,Oracle编程太不爽了
        (8)Privilege Config Tools:权限配置工具
        Windows程序,其它项目在使用此框架时,需要生成自己的的权限文件。这个工具就是用来做这件事情的。
        (9)RBAC Manager:RABC管理类
        这个是对外服务的部分,其它项目只要直接引用此dll,即可进行涉及到RBAC的各种操作。
        (10)SQLServerDAL:SQL Server 数据库访问层
        支持SQL Server数据库。也没什么好说的。
        
        现在大家可以看出来了,作为最终用户,如果在项目中使用这个框架的话,那么他所要关心的只是RBAC Manger这一个namespace下的类的使用,而无需关住RBAC的细节。

        项目组件说完了,再来介绍一下数据库建模
        说明一下,为了保证大家都能看清楚图片,所以我把图片存得大了些,右边的几个表看不见,大家费点事另存到桌面上再看吧。        

        数据库建模图:



        说一下各表的用途
        所有表均以ksRBAC开头,避免与其它项目表重名。
       (1)用户部分
        ksRBAC_Users:用户基本表。此表仅存储最少量的用户信息,用于用户登陆、权限认证等常见的工作。
        ksRBAC_UserMembership:用户权限表。此表用来存储涉及到权限系统工作的想关信息。
        ksRBAC_UserDetail:用户基本信息表。用于存储用户的日常信息。只在查看用户资料时需要调用。
        其实这个三表的内容完全可以放到一张表中,但感觉分到三个表里,在编程上会清晰一些。这里可能有不合理的地方,还望大家指正。      
        (2)权限部分
        ksRBAC_ResourceGroups:资源分组。用于将同类资源进行分组,以方便管理,支持多级分类。
        ksRBAC_Resources:资源。记录具体的资源对象。
        ksRBAC_Operations:操作。记录具体的操作方法。
        ksRBAC_Privileges:权限表。通过结成“资源-操作”对,来实现权限的定制。
        (3)角色部分
        ksRBAC_Roles:角色表。存储所有角色。
        ksRBAC_PrivilegeInRoles:用户表,用于存储与身份验证有关的信息
        ksRBAC_UsersInRoles:用户所属角色表。通过此表来设定用户具有那个角色的权限。
        (4)分组部分
        ksRBAC_Groups:分组表。存储分组相关信息
        ksRBAC_GroupsInGroups:组属组表。设置分组所属的分组。
        ksRBAC_GroupEstates:组状态类型表。
        ksRBAC_UsersInGroups:组属用户表。设置用户所属组。
        ksRBAC_UserInGroupEstates:组用户状态类型表。用于记录组中用户的状态。       
       (5)日志部分
        这部分的内容还没有做完,因为现在还没有进展到涉及日志的操作,所以不能决定到底需要什么东西。
        ksRBAC_UserLog:用户日志。用于记录用户操作

        对于用户、权限、角色三部分的表,大家应该都没有什么疑问,稍微有些理解上的差异也也该是设计习惯不同造成的。感觉主要会在分组这一块有不同的理解。看了一些相关文章,也有涉及到分组设计的,但这些设计从功能上来讲相差甚远。有的是将分组与角色关联,相当于做了一个RoleGroups表,这种分组起到了分类角色的作用。有的是将分组作为一个组织结构架构来做,然后再与用户关联,这种分组起到了分类用户的作用。本项目中的分组,是与用户相关的,而与角色无关,它实现的是用户分类的功能。但分组在这里并不仅仅起到一个分类用户的功能,还有一个重要的功能,但因为每进行具体的代码编写,所以现在还不好说,我会在完善以后写出来的。
 
        本来还有许多想写的,但是刚开始感觉思路上不是特别清晰,有些无从下笔,一些东西也不清楚是不是有必要说,就此打住吧。看看大家反馈,再决定需要写些什么内容吧。欢迎大家拍砖。
        
        第一篇文章,其实并没有涉及到具体的技术细节,只是从整体上俯瞰一下这个项目。如果您没有用过RBAC,肯定会感觉到有些不知所云。以后我会在涉及到细节的地方详细讲解的。
        下篇预告:Privilege Config Tools,权限配置工具的目的,功能与使用
posted on 2008-01-26 10:16 笨笨的考拉熊 阅读(2974) 评论(27)  编辑 收藏

FeedBack:
2008-01-25 15:38 | 菌哥      
关注!
  回复  引用  查看    
2008-01-25 15:40 | ssjh [未注册用户]
AzMan不好用么?
  回复  引用    
2008-01-25 15:41 | applethink()      
有几个表看不见,楼主修正一下。
  回复  引用  查看    
2008-01-25 15:43 | applethink()      
to: ssjh
AzMan 是什么?
  回复  引用  查看    
2008-01-25 16:04 | 墙外行人      
确实只有框架
  回复  引用  查看    
2008-01-25 16:17 | arcticfox [未注册用户]
1:UserGroup 和 Role 有什么区别吗
2:在使用框架过程中Resource 和 在程序中如何进行绑定。数据库中的记录和程序的中的资源如何进行1对1的联系。
3:Operations 表中表示具体的操作,是要在程序中定义枚举类型来和具体的操作进行绑定吗,如何动态的进行权限的扩充。

  回复  引用    
2008-01-25 16:32 | ssjh [未注册用户]
真搞不清楚这些同学重复造轮子到底是好玩还是无知。在我看来,在windows下,不管用不用AD,AzMan已经非常强大了。
google azman
  回复  引用    
#8楼 [楼主]
2008-01-25 16:55 | 苯苯的考拉熊      
@ssjh
azman自有它的优势,但文中也说过了,有些东西,虽然大且完善,但并不见得适合自己。虽然自己做出来的东西肯定不如人家的好,但在做项目的过程中,得到的收益可不是简单的引用一个现成的东西可比拟的。
前面也说了,我写这篇文章不是为了给别人建立范本,只是想把自己的心得发出来,供大家讨论,如果从中能汲取有益之处,自己也会在编程中能够少走一些弯路。
  回复  引用  查看    
#9楼 [楼主]
2008-01-25 16:55 | 苯苯的考拉熊      
@墙外行人
呵呵,不好意思,点错了按钮,没写完就发出去了。
实在是抱歉
  回复  引用  查看    
#10楼 [楼主]
2008-01-25 16:56 | 苯苯的考拉熊      
@applethink()
为了保证让大家能看清楚,所以我图片存得大了些,大家另存到桌面上就可以看全图了。

  回复  引用  查看    
#11楼 [楼主]
2008-01-26 10:28 | 苯苯的考拉熊      
@arcticfox
问题1:这个文章中已经写了,我开始没发全,不好意思。
问题2:Resource并不是直接和程序绑定,而是在程序运行中通过权限验证来自动决定是否有权使用。“数据库中的记录和程序的中的资源进行1对1的联系”,我有好几种理解方法,您可以说的再详细一些么。
问题3:可以自动生成Privilege类的。想要扩充,只要用Privilege Config Tools进行设置,并重新生成Privilege类即可。

问题2和3涉及到的这些内容我会在下一篇文章中说的。这里回答得粗糙一些,不细说了。
  回复  引用  查看    
2008-01-26 16:06 | 性感超人 [未注册用户]
程序架构晒出来看看
  回复  引用    
2008-01-26 19:08 | 学习学习了 [未注册用户]
不错不错 继续努力
  回复  引用    
2008-01-26 22:59 |       
RBAC很简单。只要知道怎么去对实体建模。剩下再用ORM实现就可以了。
  回复  引用  查看    
#15楼 [楼主]
2008-01-27 07:59 | 苯苯的考拉熊      
@辰
理论上确实不复杂。
但前面也说了,本文并不是为了讨论RBAC的理论,而是想把我建设这个系统的心得写出来。如果能对自己,和对关注这方面的朋友有一点点帮助,就很不错了。


  回复  引用  查看    
2008-01-28 09:31 | 编写人生      
功能太简单了点吧?
  回复  引用  查看    
#17楼 [楼主]
2008-01-28 10:21 | 苯苯的考拉熊      
@编写人生
能说说还缺什么东西么?
  回复  引用  查看    
2008-01-29 13:53 | Clark Zheng      
关注,关注实现。。。
  回复  引用  查看    
2008-01-29 19:23 | JoeLee [未注册用户]
粗略看了下.
你的设计过于冗余了.RBAC只需要Employee, Group,Role,Right,Relation这么几个模型就行了.
其他只关心的你的权限验证,在RBAC中.权限验证是跟会话相关的.不知道你是如何定义这个会话的.是一次Request请求算所一次会话呢还是一次登陆作为一次会话呢?
  回复  引用    
#20楼 [楼主]
2008-01-29 21:52 | 苯苯的考拉熊      
@JoeLee
呵呵,果然只是粗略看了一下。
文中已经说了,本文不是为了讨论RBAC的模型理论,而是为了使其它项目不再关心RBAC相关的内容的而建立的。如果只有你说到的这几个模型,那只能达到理论需求。
至于会话相关等问题,文中也简略的提了一下,以后涉及到的时候我会再展开说的的。
  回复  引用  查看    
2008-01-30 13:25 | JoeLee [未注册用户]
@楼主
ksRBAC_UsersInGroup
ksRBAC_GroupInGroup
ksRBAC_UsersInRole
ksRBAC_PrivilegeInRole
以上几张表明明可以合并成一张表的.都是在描述Relation.
这样你可以在你的BLL和DAL层省下很多事情的.Model也会少很多.

我们的RBAC就只有我提到5种对象,也运行的好好的.不是理论模型,是实际应用了很久了.

园子里的蔡克伦写的PermissionBase(现在好像叫PJBase了)RBAC非常好的.建议你看看.

另:还是没看到你关于会话的内容在哪里.

  回复  引用    
#22楼 [楼主]
2008-01-30 16:05 | 苯苯的考拉熊      
@JoeLee
如何合并到一张表里,你的意思是不是将Users与Groups表直接关联,而不用UsersInGroups作为中介?

会话的内容,等到这部分会写的:
(4)Demo for WebForm:B/S模式界面模板
提供Web项目的界面文件与操作代码。如果不想自己设计Web界面,可以直接使用此界面。否则只要制作新的CSS文件,替换原有css文件,即可实现自己的界面。

  回复  引用  查看    
2008-02-01 10:36 | JoeLee [未注册用户]
@楼主
我的意思是你以上几张表都在维护树的父子关系.
你只需要一张表就可以代替.
比如 RelationId, Parent, Child, ParentType, ChildType
这么几个字段就可以解决了
对于用户和组织的关系,你可以设置ParentType为Group,ChildType为User
对于组织和组织的关系,你可以设置ParentType为Group,ChildType为Group
.你搞了很多表.太拘泥于数据库的范式了.
写数据库访问要多写几个表的.
  回复  引用    
#24楼 [楼主]
2008-02-01 15:57 | 苯苯的考拉熊      
@JoeLee
多谢JoeLee兄的指点,同时也谢谢各位提出建议的朋友么。

不过我还是没看太懂,你的意思是不是用一个表来替代前面提到的4个表,用于维护用户与角色、用户与分组、资源与资源组、权限与角色之间的关系。那么这样的表怎么建立外键?如果不建外键,效率会不会很受影响。而且4个表的东西放在一起不是很乱么,读取某个部分时,另外三部分不相干的也要被访问然后筛选出去,不是降低了效率吗。

还有,这四个表并未对我的BLL,DAL,Model产生什么影响啊,因为它们只代表关系,不是实体,根本就不用为其建立对应的Model。放到4个表里和放到一个表里,对于某一个组合的操作来说,是没有区别的,要不它也得访问一个表啊。但如果放到一个表里,感觉反倒会增大代码量,因为不好处理关系了。
  回复  引用  查看    
2008-03-24 17:01 | 也算赌徒      
0.0~今天突然发现google有个博客搜索的功能.刚巧昨天又重新看了一下RBAC的内容.这么巧就来到你这了^__^

@JoeLee
我很久很久以前有个朋友跟我说过.
数据库设计的时候,有个原则:多建表,少建字段.

@苯苯的考拉熊

我那个没有继续在写了.后来想了想没有一个权限系统会适合所有的需求.
要写一个通用点的权限系统.还是只实现 高层吧.

数据库属于实现细节,还是具体情况具体分析了.
  回复  引用  查看    
#26楼 [楼主]
2008-03-24 22:02 | 笨笨的考拉熊      
@也算赌徒
好久没见啦,最近可好啊,怎么联系你呢?加我QQ吧:279983005。

现在这个系统我正在做框架,并且已经在一个项目中开始引用了,当然在引用过程中又发现了很多问题,等解决后,能够让这套系统能在这个项目中正常运用了,我会继续往下写的。

至于你说的没有一个权限系统会适合所有的需求,这是肯定的。我的目的也不是做一个全能系统,而只是想把权限验证这一部分独立出去,实现复用。而且我也不是为了商业化而做的,通不通用不是我所在意的。只要自己够用就行了。也不要说难以实现,因为现在整个系统的框架已经差不多了。虽然我为此用了一个多月的时间,而且还有继续做,但毕竟离我的目标已经越来越近了。

  回复  引用  查看    
2008-03-31 11:34 | 阿贼 [未注册用户]
呵呵,加油,看了你的文章,我受到了一点启发,谢谢啊。等实现了,继续发帖。
  回复  引用    

标题  
姓名  
主页
Email (只有博主才能看到) 
验证码 *  看不清,换一张 [登录][注册]
内容(请不要发表任何与政治相关的内容)  
  登录  使用高级评论  新用户注册  返回页首  恢复上次提交      


相关链接:
 

<2008年1月>
303112345
6789101112
13141516171819
20212223242526
272829303112
3456789

与我联系

搜索

 

常用链接

留言簿(1)

我的标签

随笔分类(1)

随笔档案(9)

文章分类(6)

文章档案(7)

积分与排名

  • 积分 - 17241
  • 排名 - 2198

最新随笔

最新评论

阅读排行榜

评论排行榜