应用程序权限设计

我们在开发系统的时候，经常会遇到系统需要权限控制，而权限的控制程度不同有不同的设计方案。

 

1.       基于角色的权限设计

这种方案是最常见也是比较简单的方案，不过通常有这种设计已经够了，所以微软就设计出这种方案的通用做法，这种方案对于每一个操作不做控制，只是在程序中根据角色对是否具有操作的权限进行控制；这里我们就不做详述

2.       基于操作的权限设计

这种模式下每一个操作都在数据库中有记录，用户是否拥有该操作的权限也在数据库中有记录，结构如下：

但是如果直接使用上面的设计，会导致数据库中的UserAction这张表数据量非常大，所以我们需要进一步设计提高效率，请看方案3

 

3.       基于角色和操作的权限设计

如上图所示，我们在添加了Role，和RoleAction表，这样子就可以减少UserAction中的记录，并且使设计更灵活一点。

但是这种方案在用户需求的考验之下也可能显得不够灵活够用，例如当用户要求临时给某位普通员工某操作权限时，我们就需要新增加一种新的用户角色，但是这种用户角色是不必要的，因为它只是一种临时的角色，如果添加一种角色还需要在收回此普通员工权限时删除此角色，我们需要设计一种更合适的结构来满足用户对权限设置的要求。

 

4.       2,3组合的权限设计，其结构如下：

我们可以看到在上图中添加了UserAction表，使用此表来添加特殊用户的权限，改表中有一个字段HasPermission可以决定用户是否有某种操作的权限，改表中记录的权限的优先级要高于UserRole中记录的用户权限。这样在应用程序中我们就需要通过UserRole和UserAction两张表中的记录判断权限。

到这儿呢并不算完，有可能用户还会给出这样的需求：对于某一种action所操作的对象某一些记录会有权限，而对于其他的记录没有权限，比如说一个内容管理系统，对于某一些频道某个用户有修改的权限，而对于另外一些频道没有修改的权限，这时候我们需要设计更复杂的权限机制。

 

5.       对于同一种实体（资源）用户可以对一部分记录有权限，而对于另外一些记录没有权限的权限设计：

对于这样的需求我们就需要对每一种不同的资源创建一张权限表，在上图中对Content和Channel两种资源分别创建了UserActionContent和UserActionChannel表用来定义用户对某条记录是否有权限；这种设计是可以满足用户需求的但是不是很经济，UserActionChannel和UserActionContent中的记录会很多，而在实际的应用中并非需要记录所有的记录的权限信息，有时候可能只是一种规则，比如说对于根Channel什么级别的人有权限；这时候呢我们就可以定义些规则来判断用户权限，下面就是这种设计。

 

6.       涉及资源，权限和规则的权限设计

在这种设计下角色的概念已经没有了，只需要Rule在程序中的类中定义用户是否有操作某种对象的权限。

以上只是分析思路，如果有不对的地方，请大家指正。

FeedBack:

# re: 应用程序权限设计 2007-04-15 16:10 aspnetx

这种表达方式最简洁明了了  回复  更多评论
  

# re: 应用程序权限设计 2007-04-15 16:14 傻子

不错,好东西  回复  更多评论
  

# re: 应用程序权限设计 2007-04-15 16:59 玉开

@傻子
@aspnetx
大家有什么好的想法，设计说一下呀
  回复  更多评论
  

# re: 应用程序权限设计 2007-04-15 18:12 狂图

直接看Rbac理论  回复  更多评论
  

# re: 应用程序权限设计 2007-04-15 18:27 龙昱帅帅NET，正在学英语

很好  回复  更多评论
  

# re: 应用程序权限设计 2007-04-15 19:44 aspnetx

@玉开
对于3,我经常用,在用户对权限的需求不是很变态的情况下
对应于4, 和微软windows里用户和组的方式一样,也就是既可以对一个组授权,也可以对一个用户授权.验证操作权限的时候就要跑两个表.
5和6就没接触过这么复杂的了  回复  更多评论
  

# re: 应用程序权限设计 2007-04-15 20:05 玉开

@狂图
多谢推荐  回复  更多评论
  

# re: 应用程序权限设计 2007-04-15 20:05 玉开

@aspnetx
5，6对于同一种事物有了不同的权限设置，是更复杂了一些  回复  更多评论
  

# re: 应用程序权限设计 2007-04-15 20:08 双鱼座

给个提示,其实你还可以这样(替换你的方案4)：

  回复  更多评论
  

# re: 应用程序权限设计 2007-04-15 20:19 玉开

@双鱼座
你的方法是通过定义UserGroup，然后给UserGroup授权，对吗？

btw，你画的图真漂亮，不知道是什么画的。  回复  更多评论
  

# re: 应用程序权限设计 2007-04-15 21:33 提问

想知道6的实践案例！！！  回复  更多评论
  

# re: 应用程序权限设计 2007-04-15 21:42 提问

@双鱼座
阁下的方案好像还是不能很好的解决临时特殊用户的资源访问授权，是不是还是如博主的直接设置user来的实在，请赐教。  回复  更多评论
  

# re: 应用程序权限设计 2007-04-15 22:02 玉开

@提问
举个例子，比方说我们要为一个公司做一个系统，在公司中每一个员工都有一个职位，对于每一个员工都可以通过职位和权限判断出员工是否有操作某个事物的权限，例如：员工A是项目部经理系统规定他可以直接审批合同交易金额在200万以下的合同交易；这就是一种规则，在程序中表达是

有这样一个类
public class ContractRule:Rule
{
//实现这种规则的代码
public override bool HasPermission(Guid userID,Guid contractID){}
}
而在数据库中记录情况是在ActionRule表中添加一条记录，这条记录中记录了上面这个类的全名和所在程序集；还需要在Action这张表中添加一条修改合同的Action；这样就可以在执行这条action的时候通过反射得到对应的规则实例计算用户是否有权限在指定的合同编号的合同上面执行操作。  回复  更多评论
  

# re: 应用程序权限设计 2007-04-15 23:50 双鱼座

@玉开
principal只是抽象的权限所有者，user和group都是principal的派生类。无论是user还是group都可以单独获得权限。此图是一个典型的鱼尾ER图，用visio所画。
@提问
给user授权或者给group授权都是通过给principal授权来解决的。哪里不够实在了？相反，这是最灵活的方案。当然，如果需要涉及与资源相关的授权，这个方案是不够的。所以我的方案仅仅对应楼主的方案4，我已经有说明。对于与资源相关的授权，的确需要涉及到复合主键：被授权者、权限、权限相关的资源。不过我也有对应的解决方案。  回复  更多评论
  

# re: 应用程序权限设计 2007-04-16 07:46 挺不错的

有没有现成的程序框架。
  回复  更多评论
  

# re: 应用程序权限设计 2007-04-16 09:02 玉开

@挺不错的
目前没有，如果说有那就是微软实现的那个了  回复  更多评论
  

# re: 应用程序权限设计 2007-04-16 09:03 玉开

@双鱼座
你的方式确实要更灵活一点，第一次听说鱼尾ER图，有空研究一下。

另外非常想看一下你的对于资源的授权的解决方案。