曾看过ofbiz关于权限设计的相关资料,感觉ofbiz在实现方面有很大的通用性。看过之后,总觉得自己理解的不够透彻,希望大家能详细的讲解一下,谢谢。

RBAC是什么意思,是哪几个词的缩写?

role based access control

可以试一试tiles,应该很简单的。用户权限必须在配置文件中写死。

> 可以试一试tiles,应该很简单的。用户权限必须在配置文件中
> 此馈?

呵呵,你说的跟上面讨论的可不是一个概念噢,这些权限是无论如何不能写死的。

没想到几天没来,这个帖子居然让banq提到首页了,乐

感谢各位的指点,我已经将这套系统的大概框架画出来了(具体实现还得等一阵^_^),首先感谢iceant,他的回复很大地扩展了我的思路,我在其它相关帖子中发现了iceant的大量发言,看来iceant是作新闻系统的啊,很多例子中举到了:)

不过,上述的讨论并不能完全套用的我的这个系统中,不知各位看明白我的提问了吗(没看明白?看来我还得好好进修一下语文-_-),在我的系统中不光有功能模块的划分(或说是功能点,显得更细),这方面的权限管理相对比较简单,不管怎样,只需将权限控制到功能点即可,也可以使用角色、组等方便配置。

而在我的这个系统中,有一个很重要的要求就是,信息权限的管理,也就是说权限要划分到某个功能点下的某条具体的信息上去,也就是说,一条信息刚录入到系统中,管理员要对其进行权限控制,那些人或那些组织或那些自定义组成员可以看到该信息,并分别可对该信息拥有什么样的权限(增删改等),当然,绝大多数用户只能拥有浏览的权限,但是在浏览权限方面又有控制,那些用户(或组织、或自定义组)可以看到哪些字段内容是不一样的,这就比较复杂了。

我后来的解决思路是:
对模块(或曰功能点)划分角色,同时对角色赋一些初始权限,这个初始权限主要是针对管理员的,也就是说初始对管理员赋所有权限,一个用户只拥有一个角色。
为了便于信息权限的控制,使用了自定义组的方式,将那些具有相同信息操作权限的人员划分到一个组中。将信息权限(包括字段权限控制)单独进行控制,也就是说除了管理员的初始权限外,这部分的权限控制不再与角色发生关系,而是由管理员对每条记录(当然可以批量操作)指定权限,权限控制到个人、组织和自定义组,在同时也将字段权限进行划分,按照一定的字符规则存储到数据库中去。
不过这样做之后,所谓通用性嘛,就不考虑了

最近,头儿也要我们做一个权限管理方面的通过系统,真是无从下手!

这个东东想搞个通用的确实很难,就像openAcl,我就基本没法拿过来用,不过实现的思想倒是可以好好研究的。
我打算把我这个东东实现之后,看看能不能提取出来

> 这个东东想搞个通用的确实很难,就像openAcl,我就基本没?> 拿过来用,不过实现的思想倒是可以好好研究的。
> 我打算把我这个东东实现之后,看看能不能提取出来

不好意思,写错了,应该是pow2acl

不好实现啊,想想一个修改操作包括n个字段,那就要分解成n个操作。控制要求高效,分配要求能做到友好,难啊。

我是新来的~~~ 第一次发言:〉俺是初学,献丑了

User Group Permission Subject Operation
前面iceant提到了这几个表,
其中Operation对应于Subejct的操作
如Modify,Delete等等

我想,是否可以再增加2个,如Column与ColumnVisible这两个表(或类)
Column: id,table,column_name,aliasvalue
ColumnVisible:格式类似于 1-1010101010这样,表示id为1的表列可见与否,这就相当于Group,就像将Subject与Operation重新细化并关注
于不同的层面,即更微观的部分 其他的就类似啦

每个User可以持有一个或多个ColumnVisible属性
根据该属性来判断该用户在某条信息中,能够看到什么东西
同时与Operation进行检测,该用户可以拥有Delete等
但View与Modify等,仅能够操作他可以处理的列


权限系统确实是可大可小的系统,很难说有一个通用的。

有时我的客户说只要最简单的 User -> Subject ACL 控制就可以了,但是有时又提出更复杂的要求....

因为公司整个内联网的应用框架是我一个人在规划,所以,我可以设计出一套在公司内, 应用之间比较通用的模型(还在设计规划过程中,也许明年初我会实现它)。

在我现在的模型中,除了上面的 Subject,User,Role,Group,Permission,Operation 这些概念外,还有 Scope 和 Appointment
我引入 Scope 这个概念,就是为了做到比较通用,因为 上面的 Subject,User,Role,Group,Permission, Operation 等等,都是在一定空间内存在的。拿 Domain 来举例,例如: domainA\UserA 是在 domainA 内的用户, domainB\UserA 是在 domainB 内的用户, 这两个域中都有叫 UserA 的用户,但是他们所指向的人确是不同的,这里就需要引入 Scope 的概念,除了 User, 其它的 Object 都是在一定 Scope 内存在的,超出一定的 Scope, 同样叫做 UserA 的人就是不同的人,他们拥有的权限可能就不一样了。

Appointment 在我的设计中,主要是面向时限控制的,例如在 workflow 这样的系统中,有时一个 manager 要出差,在公司外面因为各种原因不方便做审批,但是公司运作不能因此而停滞了,所以需要由 manager 授权给一位员工,如一位 leader, 但是这样的授权需要有个时限,如 manager 需要出差两个星期,这两个星期内的审批权,他可以转授给 leader, 所以,一个 appointment 可能包括了 assigner,receiver,time_period[from,to], subject, operation....


这样,当 leader 在对 subject 使用 operation 时,系统就会判断它是否是 receiver, 还有,操作的 time_period 是否有效等等~~

我觉得权限系统最根本的就是理顺几个重要实体的ER关系就ok了,具体用什么形式实现你的权限系统设计,方式可以千差万别,我们就曾经在j2ee的系统里面用pb做了一个权限系统(时间紧迫),也不错。???

第一次发言,没有好话,先泼点水。
我实现过一个类似复杂的权限管理系统,用B/S结构。用户用了半年后,我不得不改得简单了。原因是用户根本不会使用这个复杂的授权系统。半年内的授权工作都我们工程师做的。悲哀!
先提醒一下,用户经常是放大自己的能力的。用户真的需要如此复杂的权限管理吗?我对此表示怀疑。


Lee S

TO: Lee_sure

你说的很对,用户提出需求的时候往往是天马行空,这充分体现了人类思想的伟大。

不过对于我们这些工程师来说,如果不能很好的控制需求,那只能任由客户拖着到处跑,最后累的往往就是自己。

我现在的做法是要求客户提供需求说明书,字数多少,详尽与否我不在乎,我只是想通过这个环节让用户想清楚他到底需要什么。这样的做法实行了半年多,从实效来看,大部分的用户都能理解,但是,还有一些不尽如人意的地方,因为我发现有些客户提供的需求还是很简单,没有实质的改进,像是没有想过一样,对于这样的需求,往往在收到需求说明书后,我会再写一份比较详尽的,然后再让用户看看是否是他所要求的。这样一来需求确定的周期肯定会变长,所以,下一步我打算起草一份需求规范,让用户在写需求时照着写。

TO:iceant
你的这个方式我也在用,不过我的方法是根据客户的需求出一份需求说明,然后让其签字,不过感觉此种方法少了些许的交互,感觉你的方式效果应该更好,不过这里面又牵扯到一个问题,可能用户根本就不愿意自己写这个说明书(可能他自己都不知道需求是什么),而且对于小系统还好说,对于较大规模 的系统,一个需求可能牵扯到n个人,这时候再让用户出说明书,好像有点不太现实了

不过,根据不同情况,还是让我们灵活变通吧
另外,你的那个规范文档要是出来的话,还希望能共享阿:)