权限设计

权限是极其复杂的，想用一个权限系统来解决所有问题是不现实的。权限可以简单表述为：who+which+how+operation。

一、名词

粗粒度：表示类别级，即仅考虑对象的类别(the type of object)，不考虑对象的某个特定实例。比如，用户管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例。

细粒度：表示实例级，即需要考虑具体对象的实例(the instance of object)，当然，细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建。

模型：

二、原则

权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目标。相当多细粒度的权限问题因其极其独特而不具通用意义，它们也能被理解为是“业务逻辑”的一部分。比如，要求：“合同资源只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览”。这既可以认为是一个细粒度的权限问题，也可以认为是一个业务逻辑问题。在这里它是业务逻辑问题，在整个权限系统的架构设计之中不予过多考虑。当然，权限系统的架构也必须要能支持这样的控制判断。或者说，系统提供足够多但不是完全的控制能力。即，设计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。

Domain的应用。为了授权更灵活，可以将Where或者Scope抽象出来，称之为Domain，真正的授权是在Domain的范围内进行，具体的Resource将分属于不同的Domain。权限系统最好是可以分层管理而不是集中管理。

三、实现策略

1、业务模块分别调用授权模块。授权模块维护一份权限列表，接受业务模块调用。[#1]

优点：业务模块的权限控制自主性好，自由灵活。

缺点：代码冗余，高耦合，可维护性差，扩展性差、代码重用性差。

2、切面编程AOP。将主业务逻辑与副业务逻辑解耦，在配置文件中插入验证方法[#1#2#3]。

优点：业务模块与权限模块等独立，耦合性低，扩展性高、可维护性高。

缺点：依赖于语言的动态代理特性。

3、过滤器Filter。用一个类似门禁的过滤器模块实现对资源的访问控制，Filter截取所有的Request/Response[#4]。

优点：业务逻辑与权限逻辑分离，耦合性低。

缺点：仅适用于粗粒度控制，权限数据字典与目录结构、模块方法等耦合，不能满足细粒度的控制。

四、总结