关于权限管理方案的思考

关于权限管理方案的思考

一、角色划分

首先，我们来看一个比较简单的例子：某个用户要修改某个表的数据。

在这里，我们有操作者——用户，有操作对象——某个表，还有操作方式——修改。也就是说，在这里，我们有三个角色：分别是操作者、操作对象和操作方式。

这个方案中，操作者和操作方式的粒度很小，已经不需要再划分。但是，操作对象是一个很抽象的描述，它的粒度，决定了权限方案的严密度。如果不对操作对象进行细分，它指的就是数据库中的一张表或者是软件产品中的一个功能界面。时至今日，这种权限方案已经远远不能满足我们的需求了。

比如说，我们面对以下情况：用户修改密码，管理员可以修改所有用户的信息（包括密码，防止用户遗忘密码），而普通用户则只可以修改自己的密码。

从这个例子里面，我们知道，操作对象不再是一张完整的表了，而是这张表的一部分（某几行某几列的一个区域），如果该用户的操作涉及到他的权限以外的区域，那么，不好意思，操作被拒绝。这样一来，我们完全不用担心数据安全性，哪怕是软件出现了异常（人为异常，也就是软件被攻击了）权限方案也能阻止数据被破坏。

我们通过下面这张表来分析一下上面的例子：

用户/用户组	用户表	列：用户表的字段	行：用户表的行条件	对各区域的操作
管理员	User	Name	No Filter	增删改查
		Pwd		增删改查
		Other		增删改查
普通用户		Name	User.Name=用户名	查
		Pwd		改查
		Other		改查
		Name	User.Name<>用户名	查
		Pwd		无操作权限
		Other		查
来宾用户		Name	No Filter	查
		Pwd		无操作权限
		Other		查

可以看到，在普通用户的那一块，整个用户表被分成了两块，一块是用户自己的数据信息，另一块是其他用户的数据信息，用户对这两块的操作权限不一样。

于是，我们可以根据RowFilter把整个表分成若干个结构相同的子表，这样一来，整个权限方案就成了四维权限管理模型了。

另一种情况就是针对业务的权限控制了（软件界面上的权限控制）。当然，对界面元素的控制远不能达到对数据控制那么细致，我们只能控制到用户对这个模块功能的最大权限，对于其某部分数据，则只能是通过数据库中的权限控制来实现了。

比如如上的权限方案：修改密码界面的权限控制：管理员、普通用户可以进入到修改密码模块，而来宾用户则不能进入，普通用户在修改密码模块只能修改自己的密码，修改别人的密码必须通过数据的权限控制来实现（当前大多是通过程序控制或者使用密码验证）。

二、数据结构

包含的信息：

1、  用户标识信息：用户名称或者用户ID

2、  用户所能操作的表或模块的集合

3、  对每一个表或模块，其结构如下：

用户所能操作的数据行：一般是过滤条件RowFilter

用户所能操作的字段的集合，其结构如下：

用户对该字段所拥有的操作的集合

总的来说，就是一个树形结构。

三、数据存储

数据将以xml文件形式存储，其结构如下图所示：

<User name=”Breeze”>

       <Table name=”User”>

              <RowFilter value=”UserName=@Name”>

                     <Column name=”Name”>

<Operation>查询</Operation>

                     </Column>

              </RowFilter>

<RowFilter value=”UserName=@Name”>

                     <Column name=”Name”>

<Operation>修改</Operation>

                     </Column>

              </RowFilter>

       </Table>

</User>