markyang 2005-01-12 21:51
（2）不同的Org的用户和部门是允许重复的，就是Org1和Org2里面允许有完全一样的ID（如果用ID唯一表示用户的话）的用户，这一点只是用户提出来的，如果不说服用户改变的话，该如何的考虑
（3）用户可以在不同的Dep和Org之间调动
不知道哪位高手能解决以上这两个问题，！关注
在同一系统中，怎样区别呢？？怎么也想不出！
jakarta99 2005-01-14 20:43
@N架然使用 Directory Server 硌u作容^容易

在系y之中就O定 tree Y的人TM
Orgnization, Department 及 User

另外, 你建立一 Orgnization or Department.
同r建立一 Group,
利用 ldap group 和 application role 相互 mapping,
如此, 就可以 group 定x相P的嘞.

接著, O定 policy. 利用 policies 可以做到嘞薰芸嘏c分邮,

至於人T{, 不^只是⑾到y的 enties 搬. 更不胁煌块T重} id 的}.

billywxy 2005-01-17 13:23

问题是你的权限要管理到哪儿?

1、管理到界面?(那么如何做元素与权限的维护)
2、管理到功能?(这个就简单了)
3、管理到数据库层。(实现比较复杂)

首先要确定你的需求，到底要权限管理到什么程度?!

netcom19 2005-01-18 07:42
看看 http://www.elingke.com/techdocs/bsp-user-role.asp 是不是对你有帮助
notfish 2005-01-18 15:14
以前开发短信自动办公系统的时候，也作了一些比较复杂的权限的问题，结果就是，权限时可添加，修改的，大体就是首先定义不同的权限及其对应的类，具有相同的接口，并每个有标示，这样的结果就是动态的，扩展性比较好，然后定义角色类，使之具有相同的接口，中间有个负责联系两者的一个关联，可以是数据库也可以使xml之类的，通过权限的标示和角色的标示进行关联，因为一切都是动态的，类的引入也是反射的，所以一切都是动态的，这样子在复杂的都是可以处理的。。可以尝试一下
lostsky 2005-01-24 15:48
资源概念
资源就是想要的到的最终物质,我们可以给每一个资源定义一个权限，也可以给某一类资源定义一个权限
权限概念
权限是对资源的一种保护访问.用户要访问A资源前提是用户必须有A资源的访问权限.

角色概念
实事上我们不会直接把权限赋予给用户，而是通过角色来赋予给用户,因为用户拥有某一种权限是因为用户扮演着某一种角色。
A是个经理,他管理着B公司,他拥有b,c,d的权限。实际是不是A有这个权限，而是因为Abo是经理。因为经理拥有b,c,d权限
所以很显然在权限划分上，我们会把权限赋予给某一个角色，而不是赋予给个人。这样带来的好处是
如果公司换了经理，那么只要再聘用一个人来做经理就可以了，而不会出现因为权限在个人手里导致权限被带走的情况

分组概念
只有角色是不够的，B公司发现A有财务问题成立了一个财务调查小组,然后我们赋予了这个小组财务调查员的角色(注意是赋予小组这个角色).这样这个小组的所有人员
都有财务调查的资格。而不需要给小组的每个人都赋予这个角色(实际上已经拥有了)，分组概念也适合部门，因为任何一个部门在公司里或者社会上都在扮演着一个泛的角色。

最后一个概念
判断用户有没有访问资源的权限就看这个用户有没有访问这个资源的权限,也就是说分组，分部门,分角色最终是以权限来实现对资源的访问控制

以上都是在做notes的时候的总结

minimu 2005-01-26 11:31
没有想到这么久了，大家还这么热情

最近的一段时间比较忙于一些方案，没有上论坛，看大家这么热情而我自己却总是不路面，惭愧啊

稍后会仔细拜读大家的建议，希望自己也能有点启发，不至于作一个白痴楼主哈

minimu 2005-01-26 11:38
也许可以借鉴一下xoops的思路

其实，很大程度上，上面大家也提到了，一个系统里面那些是纯粹的系统权限，那些是业务规则是很难界定和分开的，也许是一个难点，把业务规则集成进去，可以满足特殊的需求，但是系统的扩展以及通用型就很差，甚至完蛋了
xoops我粗略的看了一下，其实是一种插件的模式（对使用者而言），感觉里面有些可以借鉴的东西

学习中，稍后汇报

liusj2005 2005-03-01 20:30
建议装 一套 微软 的 CRM系统 ，研究其权限
Joo 2005-03-09 16:43
可以试着做一颗二维的权限树，纵维（即树干部分）用于划分功能权限，父节点拥有子节点的权限。横维（即树叶）用于划分数据权限，横维必须依附在纵维的节点上，拥有该节点的纵维一定拥有该节点的所有横维，横维权限有拥有该纵维权限的节点指派。将节点成组为一个角色，分配给用户。
kongxx 2005-04-07 16:19
将系统中的功能模块化，然后对每个模块作配置，然后部署、升级、卸载，这是我的一个大概想法，大家看看行不？以下是我的部署描述符：

asddjx 2005-04-21 11:05
偶去年做了一个这样的东西，到目前还没遇到实现不了的组织结构。基本思路是：首先将系统分为两部分，一是权限继承计算部分，纯数学模型；二是跟业务系统的接口部分，里面包含着业务规则、权限数据缓冲策略。接下来确定数据结构，用户部分的组织形式是：首先，系统有一个虚拟的根即“任何人”，不需要明确声明，任何用户和用户组都挂在这个根上；然后，规定用户组可以隶属多个用户组，只要不形成循环，可以随便组织，人员可以隶属多个用户组。也就是用户和组可以形成一个有向图。资源的组成形式跟用户的组成形式一样，有一个虚拟总根“所有资源”，其他完全一样。权限数据表就是简单的列表了，用户标识＋资源标识＋权限设置值。再接下来确定权限计算规则。有了以上过程，继承权计算的数学模型就出来了，第一部分就完成了。第二部分的工作就是跟用户讨论怎么用第一部分的问题了。
大愚弱智 2005-04-28 16:49
我手头上做了一个demo，Spring＋Hibernate做的：
实体关系如下：
组是树形结构(也就是自身的多对一和一对多)，
组和用户是一对多，
组和角色是多对多，
用户和角色是多对多，
书和角色是多对多，

当前登陆用户所能看到的书的权限计算如下（下面所说的集合是指数学中的集合，即集合不允许元素重复）：
找出用户的所有直接权限集合R1，
找出用户所在组的所有直接权限集合R2，
找出用户所在组的所有子组的集合G，
找出G的所有权限的集合R3，
取R1、R2、R3的并集R，
R的所能看到的书的集合B就是用户所能看到的书 ，

另外, R是用户所具有的所有角色

目前我已经完成后台管理的大部分：
对书的增删改查，
对用户的增删改查，
对角色的增删改查，
对组的增删改查、把用户加入某一个组、给某一个组加角色、计算该组的所有直接关联用户、计算该组所有用户、计算该组的所有直接关联角色、计算该组的所有角色
zhangqinfen 2005-04-30 13:46
我在做系y的r候也遇到了同拥}
高手多多指教
s3boy 2005-05-03 22:14
偶去年做了一个这样的东西，到目前还没遇到实现不了的组织结构。基本思路是：首先将系统分为两部分，一是权限继承计算部分，纯数学模型；二是跟业务系统的接口部分，里面包含着业务规则、权限数据缓冲策略。接下来确定数据结构，用户部分的组织形式是：首先，系统有一个虚拟的根即“任何人”，不需要明确声明，任何用户和用户组都挂在这个根上；然后，规定用户组可以隶属多个用户组，只要不形成循环，可以随便组织，人员可以隶属多个用户组。也就是用户和组可以形成一个有向图。资源的组成形式跟用户的组成形式一样，有一个虚拟总根“所有资源”，其他完全一样。权限数据表就是简单的列表了，用户标识＋资源标识＋权限设置值。再接下来确定权限计算规则。有了以上过程，继承权计算的数学模型就出来了，第一部分就完成了。第二部分的工作就是跟用户讨论怎么用第一部分的问题了。

前辈 能否 细说一下你的模型 ?觉得很好,可是还无法理解怎么去实现