关于权限管理方案的思考

关于权限管理方案的思考[/b]
一、角色划分
首先，我们来看一个比较简单的例子：某个用户要修改某个表的数据。
在这里，我们有操作者——用户，有操作对象——某个表，还有操作方式——修改。也就是说，在这里，我们有三个角色：分别是操作者、操作对象和操作方式。
这个方案中，操作者和操作方式的粒度很小，已经不需要再划分。但是，操作对象是一个很抽象的描述，它的粒度，决定了权限方案的严密度。如果不对操作对象进行细分，它指的就是数据库中的一张表或者是软件产品中的一个功能界面。时至今日，这种权限方案已经远远不能满足我们的需求了。
比如说，我们面对以下情况：用户修改密码，管理员可以修改所有用户的信息（包括密码，防止用户遗忘密码），而普通用户则只可以修改自己的密码。
从这个例子里面，我们知道，操作对象不再是一张完整的表了，而是这张表的一部分（某几行某几列的一个区域），如果该用户的操作涉及到他的权限以外的区域，那么，不好意思，操作被拒绝。这样一来，我们完全不用担心数据安全性，哪怕是软件出现了异常（人为异常，也就是软件被攻击了）权限方案也能阻止数据被破坏。
我们通过下面这张表来分析一下上面的例子：

用户/用户组	用户表	列：用户表的字段	行：用户表的行条件	对各区域的操作
管理员	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>