[iceant]
Re: 我也请教一个关于权限设计方面的问题
能不能详细说说你的应用情景? 举个例子
[ninsky]
Re: 我也请教一个关于权限设计方面的问题
> 能不能详细说说你的应用情景? 举个例子用户、单位等信息存储在LDAP中，而且是远程的，我的系统虽说取的是LDAP中的用户、单位信息，可是还得提供额外的用户、单位增加功能，也就是说在读取用户、单位信息时要将LDAP中的信息与自己增加的用户、单位信息汇合，重新进行树状排列（这个地方采取生成XML树的方式，不知效果如何），与此同时还要判断当前用户的权限，以便控制各节点是否显示（这些节点可能是单位，也可能是个人）。然后对各个节点显示的信息还得读取控制权限，那些信息可以显示，那些不能显示，另外对各个信息的操作权限也有控制，对某条信息是增、删、改，还是仅仅查看。而对于某条记录的详细信息，又需控制某个字段是否显示，等等等等，如此这般我的初步构想：
划分功能点：功能模块（不同用户有不同的操作模块，如我们一般程序顶的菜单项，非LDAP和相关信息）、表结构（数据字典表，控制到字段权限时用）
操作（operate）：增、删、改、查看
角色：赋功能模块，及相关操作
用户：赋角色
组：赋用户算了，就说这点吧，我也晕了，现在思路很乱
==============================================================================
[iceant] Re: 我也请教一个关于权限设计方面的问题
我的感觉是你对需求不明确，建义你回去和客户坐下来谈谈他们想要的东东。你可以把操作的界面画出来，然后问问客户是不是想这样操作，如果不是，怎么改动，最后要一个需求更改说明书(可能要你写，客户签字，这也是对你自己的一种保护!)，说明确定下来的需求是什么。所谓有的字段显示，有的字段不显示，多数情况下在程序设计与实施阶段都可以确定的，字段显示就表明用户拥有某种权限，如拥有了增删改员工信息权限的用户，就能看到 Submit 按钮，而一般用户就看不到这个按钮。
==============================================================================
[ninsky]
Re: 我也请教一个关于权限设计方面的问题
呵呵，不是submit，那些倒是好说：）
例如显示页面中，有a、b、c、d等项，甲进入后可能会看到a、b项，而乙可能就是看到b、d、c等项了，是这么个意思另：iceant你好像一直挂在坛里啊
==============================================================================
[iceant]
Re: 我也请教一个关于权限设计方面的问题
>>呵呵，不是submit，那些倒是好说：）
>>例如显示页面中，有a、b、c、d等项，甲进入后可能会看到a、b项，而
>>乙可能就是看到b、d、c等项了，是这么个意思所以我请你举个例子来看看啊，不能实际把应用说清楚，就表示没有理解需求，没有理解需求，是不可能做出东西来的。即使做出来了，也只是不符合用户需求的东西。这里你可以思考一下，为什么甲进入后看到的是 a,b? 是因为甲拥有了某种权限？是甲拥有了某种身份？乙需要拥有什么样的权限或身份才能看到b,d,c?我觉得你总在说自己头痛，但并不知道自己为什么头痛。>>另：iceant你好像一直挂在坛里啊 我今天放自己假，不想做事，所以有空。有时忙起来，可能一两个月也不会上网了~~~
==============================================================================[ninsky]
Re: 我也请教一个关于权限设计方面的问题
其实，我真正头疼的是，我在考虑这个系统的设计的时候，思路老是飘到：如果这个系统更加通用的话该如何设计呢。以设计一个通用的，复用性强的系统为己任，头不疼才怪呢是时候放弃这种想法了，都是让那帮老是让那帮高人把我害的^_^
Re: 我也请教一个关于权限设计方面的问题
能不能详细说说你的应用情景? 举个例子
[ninsky]
Re: 我也请教一个关于权限设计方面的问题
> 能不能详细说说你的应用情景? 举个例子用户、单位等信息存储在LDAP中，而且是远程的，我的系统虽说取的是LDAP中的用户、单位信息，可是还得提供额外的用户、单位增加功能，也就是说在读取用户、单位信息时要将LDAP中的信息与自己增加的用户、单位信息汇合，重新进行树状排列（这个地方采取生成XML树的方式，不知效果如何），与此同时还要判断当前用户的权限，以便控制各节点是否显示（这些节点可能是单位，也可能是个人）。然后对各个节点显示的信息还得读取控制权限，那些信息可以显示，那些不能显示，另外对各个信息的操作权限也有控制，对某条信息是增、删、改，还是仅仅查看。而对于某条记录的详细信息，又需控制某个字段是否显示，等等等等，如此这般我的初步构想：
划分功能点：功能模块（不同用户有不同的操作模块，如我们一般程序顶的菜单项，非LDAP和相关信息）、表结构（数据字典表，控制到字段权限时用）
操作（operate）：增、删、改、查看
角色：赋功能模块，及相关操作
用户：赋角色
组：赋用户算了，就说这点吧，我也晕了，现在思路很乱
==============================================================================
[iceant] Re: 我也请教一个关于权限设计方面的问题
我的感觉是你对需求不明确，建义你回去和客户坐下来谈谈他们想要的东东。你可以把操作的界面画出来，然后问问客户是不是想这样操作，如果不是，怎么改动，最后要一个需求更改说明书(可能要你写，客户签字，这也是对你自己的一种保护!)，说明确定下来的需求是什么。所谓有的字段显示，有的字段不显示，多数情况下在程序设计与实施阶段都可以确定的，字段显示就表明用户拥有某种权限，如拥有了增删改员工信息权限的用户，就能看到 Submit 按钮，而一般用户就看不到这个按钮。
==============================================================================
[ninsky]
Re: 我也请教一个关于权限设计方面的问题
呵呵，不是submit，那些倒是好说：）
例如显示页面中，有a、b、c、d等项，甲进入后可能会看到a、b项，而乙可能就是看到b、d、c等项了，是这么个意思另：iceant你好像一直挂在坛里啊
==============================================================================
[iceant]
Re: 我也请教一个关于权限设计方面的问题
>>呵呵，不是submit，那些倒是好说：）
>>例如显示页面中，有a、b、c、d等项，甲进入后可能会看到a、b项，而
>>乙可能就是看到b、d、c等项了，是这么个意思所以我请你举个例子来看看啊，不能实际把应用说清楚，就表示没有理解需求，没有理解需求，是不可能做出东西来的。即使做出来了，也只是不符合用户需求的东西。这里你可以思考一下，为什么甲进入后看到的是 a,b? 是因为甲拥有了某种权限？是甲拥有了某种身份？乙需要拥有什么样的权限或身份才能看到b,d,c?我觉得你总在说自己头痛，但并不知道自己为什么头痛。>>另：iceant你好像一直挂在坛里啊 我今天放自己假，不想做事，所以有空。有时忙起来，可能一两个月也不会上网了~~~
==============================================================================[ninsky]
Re: 我也请教一个关于权限设计方面的问题
其实，我真正头疼的是，我在考虑这个系统的设计的时候，思路老是飘到：如果这个系统更加通用的话该如何设计呢。以设计一个通用的，复用性强的系统为己任，头不疼才怪呢是时候放弃这种想法了，都是让那帮老是让那帮高人把我害的^_^
[客人] Re: 我也请教一个关于权限设计方面的问题
我的项目中也碰到了类似的问题，即对于每个模块，对其下的各种资源的操作都是一种权限，比如新闻模块，“新闻”是一个资源，而“发布新闻”则是一个操作，而对“新闻的发布”则成了权限
在实际中，新闻若分部门，则“发布A部门的新闻”是一个实际的权限，在权限系统中，将个权限赋给某个角色即可，后面的都好办（参看本论坛中关于权限设计中的RBAC方面的讨论）所以系统中比一般的RBAC多了以下表：
Resource
Operation角色除了和权限对应外，还和资源实例对应，即如是A部门的则有RA角色，B的是RB，将这些角色分配给对应的用户或组后即完成授权。在权限验证的时候通过当前用户和当前可操作角色（由当前模块所对应的资源实例来确定）来验证，ACL.checkPermission(user,resource,operation)但难点在于模块和资源是变化的，新闻也许只需要一个部门ID就可以确定当前角色，对于复杂的应用如何获取当前模块资源实例并获取当前可操作角色则还没想出好的解决办法继续thinking...
==============================================================================
[ninsky] Re: 我也请教一个关于权限设计方面的问题
唉，我的问题与此类似，不过又稍微复杂了点不知可否给我发个这方面的示例图啊，当然是非机密的
也好让我研究研究以前自己写代码感觉挺爽的，再难的方法也都可以实现，可现在自己作设计，可真是感觉晕头转向的啊:(努力、奋斗
==============================================================================
[littlebird]
Re: 我也请教一个关于权限设计方面的问题
看了这么多关于权限方面的讨论真是受益匪浅。
这里说说我的想法：
我认为对于多数企业应用项目，相对而言都不是很大的项目，权限管理部分是不是可以简化成：user *-->1 role 1-->* operate
用户可能有很多组织上的层次关系，但在这里可以将它压平，不论什么层次都直接和角色相关，而且只有一个角色
权限也可能有很多层次关系（比如新闻包括A、B或C部门的），这里也把它展开，让角色直接最底层的权限相关（如A部门新闻的修改权限）
根据用户获得它的角色，再根据角色获得它拥有权限的集合。而group是用户的集合，把它加上会变得相当复杂；当然还可以有权限集合的概念也加入，那就更复杂了。
==============================================================================
[iceant]
Re: 我也请教一个关于权限设计方面的问题
我想理一理思路，看看 ACL 与 RBAC 的区别:还是以部门新闻来讨论，对于静态授权，在系统设计做需求分析的时候，往往就可以
确定一个系统角色的种类，像新闻系统中，根据需求，可能会有新闻发布者(Publisher)，
新闻审核者(Reviewer)，新闻浏览者(Visitor)，管理员(Manager)以及超级管理员(Administrator)。在设计的时候我们也已经把这些角色与相应的一些 Operation 绑定在一起。
如：Publisher 拥有 Publish_Operation + Modify_Operation
Reviewer 拥有 Review_Operation + Modify_Operation + Delete_Operation
Visitor 拥有 Visit_Operation,
Manager 拥有 Create_News_System_Instance_Operation +
Modify_News_System_Instance_Operation +
Delete_News_System_Instance_Operation
Administrator 负责 Create_User_Operation+
Delete_User_Operation+
Assign_Permission_Operation+
Deassign_Permission_Operation +
Assign_Role_Operation+
Deassign_Role_Operation在授权时，往往先为一个用户(USER)，赋予一个角色，如: Manager. 这样，USER 就
拥有了对所有 News_Instance(也就是部门新闻) 操作的权限。
现在假设用户(UserA)访问 Create_News_System_Instance 功能来创建一个新的新闻实例，
叫做 采购部门新闻. 因为我们在设计的时候就确定，该功能只能由 Manager 来访问，
于是，系统中权限的判断部分会首先判断当前用户(UserA)是否 Manager 角色，是的话就允许
访问，否则显示没有授权的错误信息。所以，对于 Manager 这样的应用:
[1] 在设计的时候，我们就将这样的角色与相应的 Permissions(A list of Subject-Operation pairs)
关联在一起了，这里的 Subject 是所有的新闻实例(News_Instance),Operation
就是 Create,Modify以及 Delete.
[2] 在授权的时候，超级管理员(Administrator)可以利用 Assign_Role_Operation 将用户(User)
与 Manager 这个角色关联起来。这样，User 就拥有了对所有新闻实例的 Create, Modify 以及 Delete
操作的权限。
[3] 在权限判断的时候，RBAC 系统首先判断当前用户是否是设计时确定的角色(这里是Manager),
如果是，就允许用户访问，否则就拒绝访问，并显示错误信息。
对于 Publisher 这样的角色有些不同，Publisher 这个角色只与 Operation 绑定在一起，并没有与
具体的 Subject 相关联，因此，在授权的时候，还需要指定相应的 Subject.所以，对 Publisher 这样只能事先确定 Operation 的应用来说:
[1] 在设计的时候，我们只能确定该角色能进行哪些操作，而不能确定这些操作实施的对象。
[2] 在授权的时候:
[2.1] 首先将 Publisher 与 Subject 关联,如将 Publisher 与采购部门新闻关联产生:
采购部门新闻_News_Publisher 的角色
[2.2] Administrator 为用户(User)授于 采购部门新闻_News_Publisher 角色。从而 User
拥有了对"采购部门新闻"的发布权限
[3] 在权限判断的时候，用户访问 采购部门新闻_News_Publish_Operation, 系统首先判断
该用户是否 采购部门新闻_News_Publisher?如果是，就允许用户访问，否则就拒绝访问，
并显示错误信息。
这里用到的方法可能是这个样子:
boolean checkPermission(采购部门新闻,Publish_Operation,User){
List publishers = RBAC.findRole(new Permission(采购部门新闻,Publish_Operation));
if(publishers==null) return false;
for(Iterator it = publishers.iterator; it.hasNext();){
Role publisher = (Publisher)it.next();
if(publisher.isAssignedWithUser(User)){
return ture;
}
}
return false;
}假如说，不采用 RBAC 的做法，考虑一下，使用 ACL，那又会是什么样子呢?
对于 Manager 那样能在设计时就确定 Subject 与 Operation 的角色，我认为没有必要考虑 ACL 了.
对于 Publisher 这样，只能事先确定 Operation 的角色，我们来做个对比.
权限系统要灵活，但是也要简洁，要不然就很可能导至失控。因为嵌套的层次太多，有可能发生不可
预知的情况. 有一天管理员可能会莫明的发现，怎么这个人会有这个权限的?
所以，我认为在 RBAC 里不支持 Role 的层级关系为妙。好了，现在来看看 ACL 对 Publisher 应用
这里指的 ACL 是直接将 User 或 Group 与 Subject 关联的做法。
User 与 Subject 是多对多的情况，
Group 与 Subject 也是多对多的情况，
同样的，User 与 Group 也是多对多的情况。现在，还是以采购部门新闻为例:
[1] 在授权的时候，可以有以下操作:
[1.1] 将 User 与 Subject 关联在一起,但是要指定相应的 Operation.
如: assignPermission(采购部门新闻,Publish_Operation,User)
[1.2] 将 Group 与 Subject 关联在一起:
如: assignPermission(采购部门新闻,Publish_Operation,Group)
[1.3] 将 User 与 Group 关联
如:
assignUserGroup(User,Group)[2] 在权限判断的时候，用户访问 采购部门新闻_News_Publish_Operation，系统做如下检查:
boolean checkPermission(采购部门新闻,Publish_Operation,User){
boolean hasPermission = false;
// users include:
// 1. Permission direct assigned Users
// 2. The user assigned with the groups that assigned with permission
List users = getAssignedUsers(new Permission(采购部门新闻,Publish_Operation));
hasPermission=users.contains(User)?true:false;
}
[ninsky] Re: 我也请教一个关于权限设计方面的问题
> 可以试一试tiles,应该很简单的。用户权限必须在配置文件中
> 此馈?呵呵，你说的跟上面讨论的可不是一个概念噢，这些权限是无论如何不能写死的。没想到几天没来，这个帖子居然让banq提到首页了，乐感谢各位的指点，我已经将这套系统的大概框架画出来了（具体实现还得等一阵^_^），首先感谢iceant，他的回复很大地扩展了我的思路，我在其它相关帖子中发现了iceant的大量发言，看来iceant是作新闻系统的啊，很多例子中举到了：）不过，上述的讨论并不能完全套用的我的这个系统中，不知各位看明白我的提问了吗（没看明白？看来我还得好好进修一下语文-_-），在我的系统中不光有功能模块的划分（或说是功能点，显得更细），这方面的权限管理相对比较简单，不管怎样，只需将权限控制到功能点即可，也可以使用角色、组等方便配置。而在我的这个系统中，有一个很重要的要求就是，信息权限的管理，也就是说权限要划分到某个功能点下的某条具体的信息上去，也就是说，一条信息刚录入到系统中，管理员要对其进行权限控制，那些人或那些组织或那些自定义组成员可以看到该信息，并分别可对该信息拥有什么样的权限（增删改等），当然，绝大多数用户只能拥有浏览的权限，但是在浏览权限方面又有控制，那些用户（或组织、或自定义组）可以看到哪些字段内容是不一样的，这就比较复杂了。我后来的解决思路是：
对模块（或曰功能点）划分角色，同时对角色赋一些初始权限，这个初始权限主要是针对管理员的，也就是说初始对管理员赋所有权限，一个用户只拥有一个角色。
为了便于信息权限的控制，使用了自定义组的方式，将那些具有相同信息操作权限的人员划分到一个组中。将信息权限（包括字段权限控制）单独进行控制，也就是说除了管理员的初始权限外，这部分的权限控制不再与角色发生关系，而是由管理员对每条记录（当然可以批量操作）指定权限，权限控制到个人、组织和自定义组，在同时也将字段权限进行划分，按照一定的字符规则存储到数据库中去。
不过这样做之后，所谓通用性嘛，就不考虑了
==============================================================================
[ninsky]
Re: 我也请教一个关于权限设计方面的问题
这个东东想搞个通用的确实很难，就像openAcl，我就基本没法拿过来用，不过实现的思想倒是可以好好研究的。
我打算把我这个东东实现之后，看看能不能提取出来
不好意思，写错了，应该是pow2acl
==============================================================================
[冰云] Re: 我也请教一个关于权限设计方面的问题
我是新来的~~~ 第一次发言：〉俺是初学，献丑了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等，仅能够操作他可以处理的列
==============================================================================[iceant] Re: 我也请教一个关于权限设计方面的问题
权限系统确实是可大可小的系统，很难说有一个通用的。有时我的客户说只要最简单的 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 是否有效等等~~
==============================================================================[javaw] Re: 我也请教一个关于权限设计方面的问题
我觉得权限系统最根本的就是理顺几个重要实体的ER关系就ok了，具体用什么形式实现你的权限系统设计，方式可以千差万别，我们就曾经在j2ee的系统里面用pb做了一个权限系统（时间紧迫），也不错。？？？
==============================================================================
[lee_sure] Re: 我也请教一个关于权限设计方面的问题 第一次发言，没有好话，先泼点水。
我实现过一个类似复杂的权限管理系统，用B/S结构。用户用了半年后，我不得不改得简单了。原因是用户根本不会使用这个复杂的授权系统。半年内的授权工作都我们工程师做的。悲哀！
先提醒一下，用户经常是放大自己的能力的。用户真的需要如此复杂的权限管理吗？我对此表示怀疑。
[iceant] Re: 我也请教一个关于权限设计方面的问题
TO: Lee_sure你说的很对，用户提出需求的时候往往是天马行空，这充分体现了人类思想的伟大。不过对于我们这些工程师来说，如果不能很好的控制需求，那只能任由客户拖着到处跑，最后累的往往就是自己。我现在的做法是要求客户提供需求说明书，字数多少，详尽与否我不在乎，我只是想通过这个环节让用户想清楚他到底需要什么。这样的做法实行了半年多，从实效来看，大部分的用户都能理解，但是，还有一些不尽如人意的地方，因为我发现有些客户提供的需求还是很简单，没有实质的改进，像是没有想过一样，对于这样的需求，往往在收到需求说明书后，我会再写一份比较详尽的，然后再让用户看看是否是他所要求的。这样一来需求确定的周期肯定会变长，所以，下一步我打算起草一份需求规范，让用户在写需求时照着写。
==============================================================================
[ninsky] Re: 我也请教一个关于权限设计方面的问题
TO：iceant
你的这个方式我也在用，不过我的方法是根据客户的需求出一份需求说明，然后让其签字，不过感觉此种方法少了些许的交互，感觉你的方式效果应该更好，不过这里面又牵扯到一个问题，可能用户根本就不愿意自己写这个说明书（可能他自己都不知道需求是什么），而且对于小系统还好说，对于较大规模 的系统，一个需求可能牵扯到n个人，这时候再让用户出说明书，好像有点不太现实了不过，根据不同情况，还是让我们灵活变通吧
另外，你的那个规范文档要是出来的话，还希望能共享阿：）
==============================================================================
[loreal] Re: 我也请教一个关于权限设计方面的问题
我认为可以使用带参数的操作来解决这个问题。基本上还是基于RBAC模型，可以对其稍微改进一下：对用户也可以单独授权。其实可以将单个用户、组或者角色都统一看待为subject（主体），将所有资源统一看待为object（客体），然后再加上带参数的操作(operation或activity），这样三元组（s，o，a）就表示了s对o所具有的a操作权限。我们对（s，o，a）再进行一下扩充（s，o，a，c），c表示condition，即
约束条件。（s，o，a，c）表示s在c条件下对o有a操作的权限。这样就很容易解决许多问题：
授权的时候将每个用户/组/角色的权限按上述四元组表示清楚即可。用户提出访问请求时，除了查看是否有与用户请求相匹配的四元组，还要看条件是否满足，条件满足的情况下，就允许用户访问；反之，拒绝。关于对表字段的访问控制，我认为如果你设计的资源管理模块能细化到字段级，那么对字段级的访问控制也就不成问题了。
==============================================================================
[wqy518] Re: 我也请教一个关于权限设计方面的问题
四元组的抽象确实很精彩！！！
权限管理中一个很重要的东西就是客体对象的粒度大小问题，如果粒度过大，则分配操作简单，但系统功能就弱了；如果粒度过小，系统很灵活，但配置非常复杂，不但开发工作量大，而且可能根本没法用。
以普通的数据库应用为例，一般控制表一级的访问即可以了，这是客体对象的基本粒度为： 表×表操作（增删改，为说明问题，直接把操作也当作对象一部分），象楼主提到的系统，基本粒度为：表×字段×记录×操作，这个量级是不得了的，再加上用户，组，权限，复杂度非常可以了。
==============================================================================
[kewan] Re: 我也请教一个关于权限设计方面的问题
这是应用AOP的一个非常好的例子！
所有的有关权限的的操作都是一个cross-cut，把权限操作从代码中解偶，非常漂亮!如果想换一种权限机制，也非常的方便。
==============================================================================[daquan198163]
Re: 我也请教一个关于权限设计方面的问题
> "对于控制到字段的权限模式你能否也提供一点建议呢"
>
> 什么叫控制到字段的权限模式?
其实“控制到字段的权限模式”并没有太大的必要，倒是有一个和它类似的需求：用过TestTrack（一种测试工具）的人一定对过滤器很熟悉吧，我觉得这个东西很有用。__________________
the answer!
==============================================================================
http://www.jdon.com/jive/thread.jsp?forum=46&thread=2897&start=0&msRange=15
约束条件。（s，o，a，c）表示s在c条件下对o有a操作的权限。这样就很容易解决许多问题：
授权的时候将每个用户/组/角色的权限按上述四元组表示清楚即可。用户提出访问请求时，除了查看是否有与用户请求相匹配的四元组，还要看条件是否满足，条件满足的情况下，就允许用户访问；反之，拒绝。
想问一下大家对权限判断是如何实现，一个一个的Operation的判断，还是用索数1、2、4、8......还是0101011110000 按位判断, 还是有什么其它的办法么?怎么没有人来讨论啊?
是周末的原因么?
我的MSN：[email protected]
prGroupUser prRoleUser prRoleGroup prPermission (psResource + psOperation) prRolePermission [角色权限表]
role | Resource
| Operation判断：通过user or group ---->>找到所属 Role --->>此角色所拥有的资源权限 Permission(根据Resource) --->>得到权限列表 (Operation)List
另外,还是要找客户谈的,看看Win2k的用户与组的设置方式,问他是不是想这样,如果他头大了,肯定就会说"是",然后你就用"计算机管理"给他做一个,呵呵,你的事情就完成了,(开玩笑啦 :D )
1.User——用户
2.UserGroup——用户组
3.Permission——权限项
4.Project——项目
5.State——状态，一个项目可有n个状态组成
6.Process——处理项，从属于State，即一个State中可进行多种处理
7.Role——用户角色
权限方面的思路就是将State与Role绑定，将User加入到Role中，通过Role-State
关系判断用户是否有进入State操作Process的权限。
因为设计出发点是一个便于开发的框架，所以开发的过程大致是这样的：
a.分析业务需求，用一个Project进行描述
b.将Project的完成分成几个步骤，每个步骤对应一个State
c.确定每个State有哪些处理要求，构建Process
d.分析用户权限，定义Role，并为每个State确定Role-State关系
e.将User加入Role
User_ID 用户ID
Group_ID 所属组
Name 真实姓名
Password 密码
Notes 用户描述Group：
Group_ID 组ID
Name 组名
Note 描述Func:
Func_ID 功能ID
Category 功能分类
Note 描述Group_Func
Group_ID 组ID
Func_ID 功能ID然后创建一视图，联系UserID和Func_ID,以后可根据UserID查询视图得到对应的FuncID:
SELECT dbo.[user].USER_ID, dbo.[group_func].FUNC_ID
FROM dbo.[group_func] RIGHT OUTER JOIN
dbo.[user] ON
dbo.[group_func].GROUP_ID = dbo.[user].GROUP_ID