粗粒度权限系统的设计

[url]http://yongta1983.blog.hexun.com/8623274_d.html[/url]
[size=medium]
权限逻辑配合业务逻辑。即，权限系统以为业务逻辑提供服务为目标。纯粹纸面意义的极其复杂和精巧的权限系统，这里不作讨论。相当多细粒度的权限问题因其极其独特而不具通用意义，它们也能被理解为是“业务逻辑”的一部分。比方，要求：“合同资源只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览”。这既可以认为是一个细粒度的权限问题，也可以认为是一个业务逻辑问题。在这里我认为它是业务逻辑问题，在整个权限系统的架构设计之中不予过多考虑。当然，权限系统的架构也必须要能支持这样的控制判断。或者说，系统提供足够多但不是完全的控制能力。即，设计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。

需要再次强调的是，这里表述的权限系统仅是一个“不完全”的权限系统，即，它不提供所有关于权限的问题的解决方法。它提供一个基础，并解决那些具有“共性”的(或者说粗粒度的)部分。在这个基础之上，根据“业务逻辑”的独特权限需求，编码实现剩余部分(或者说细粒度的)部分，才算完整。回到权限的问题公式，我的设计仅解决了 who + what + how 的问题，which 的权限问题留给业务逻辑解决。


概念：

User：用户。解决 who 的问题。

Group：组。权限分配的单位与载体。权限不考虑分配给特定的用户。组可以包括组(以实现权限的继承)。

Operate：操作。表明对 what 的 how 操作。


说明：

User

与大家的都一样，没什么好说的。

Group

与大家的类似，所不同的是，Group 要实现继承。即，在创建时必须要指定该 Group 的 Parent 是什么 Group 。在粗粒度控制上，可以认为，只要某用户直接或者间接的属于某个 Group 那么它就具备这个 Group 的所有操作许可。细粒度控制上，在业务逻辑的判断中，User 仅应关注其直接属于的 Group ，用来判断是否“同组”，间接的 Group 对权限的控制意义不大，试设想存在一个 All User 的 Group 是所有 Group 的祖先，这样的情形下，判断的结果不具备实际意义。

User 与 Group 是多对多的关系。即，一个 User 可以属于多个 Group 之中，一个 Group 可以包括多个 User 。

子 Group 与 父 Group 是多对一的关系。即，一个子 Group 只能有一个父 Group ，一个父 Group 可以包括多个子 Group 。


Operate

某种意义上类似于大家的 Resource + Privilege 概念，但，这里的 Resource 仅包括 Resource Type 不表示 Resource Instance。Operate 概念上与大家的观点区别比较，后面有详细的解释。

Group 与 Operate 是多对多的关系。

各概念的关系图示如下：
&<60;User
&<60; |*
&<60; |
&<60; |*&<60;&<60; 1
&<60;Group---+
&<60; |* |*&<60; |
&<60; |&<60; +---+
&<60; |*
&<60;Operate


解释：

Operate 的定义包括了 Resource Type 和 Method 概念。即， what 和 how 的概念。之所以将 what 和 how 绑定在一起作为一个 Operate 概念而不是分开建模再建立关联，这是因为很多的 how 对于某 what 才有意义。比方，发布操作对新闻对象才有意义，对用户对象则没有意义。

how 本身的意义也有所不同，这里并非仅定义类 UNIX 的 RWX 三种操作，这样的定义对于文件系统是合理的，但，对于其他的应用领域或许就不是那么足够了。具体来说，对于每一个 what 可以定义 N 种操作。比方，对于合同这类对象，可以定义创建操作、提交操作、检查冲突操作等。可以认为，how 概念对应于每一个商业方法。

其中，与具体用户身份相关的操作既可以定义在操作的业务逻辑之中，也可以定义在操作级别。比方，创建者的浏览视图与普通用户的浏览视图要求内容不同。你既可以在外部定义两个操作方法，也可以在一个操作方法的内部根据具体逻辑进行处理。具体应用哪一种方式应依据实际情况进行处理。

这样的架构，应能在易于理解和管理的情况下，满足绝大部分粗粒度权限控制的功能需要。但是，除了粗粒度权限，无可否认，系统中必然还会包括无数对具体 Instance 的细粒度权限。这些问题，被留给业务逻辑来解决，这样的考虑基于以下两点。

一方面，细粒度的权限判断必须要在资源上建模权限分配的支持信息才可能得以实现。比方，如果要求创建者和普通用户看到不同的信息内容，那么，资源本身应该有其创建者的信息。如同 Unix 的每一个文件(资源)，都定义了对 Owner, Group, All 的不同操作属性。

另一方面，细粒度的权限常常具有相当大的业务逻辑相关性。对不同的业务逻辑，常常意味着完全不同的权限判定原则和策略。相比之下，粗粒度的权限更具通用性，将其实现为一个架构，更有重用价值；而将细粒度的权限判断实现为一个架构级别的东西就显得繁琐，而且不是那么的有必要，用定制的代码来实现就更简洁，更灵活。

[/size]