java权限设计探讨--释放用户特权(初篇)

     权限设计对于系统来说是一套资源防御系统，避免不同用户种类越权使用。这几天看了一些权限设计设计，但还是感觉他们似乎还是有点欠缺，首先我比较关注RBAC，RBAC提供3套权限设计模式。
    首先看第一种RBAC0,RBAC0 定义了能构成一个RBAC控制系统的最小的元素集合，这种模式是早期业界非常普遍的模式，让用户关联角色，角色组合多个权限资源。但现在的业务越来非常，要求人性化更多一点，设计更合理些，加入用户需要超越自己所在的角色扩展其他的权限，就会带来很大困难的扩展。
    RBAC1,RBAC1 引入角色间的继承关系.这个突破带来了角色之间的继承关系，从而让一个用户由可以充当多种角色。可以说这是权限发展史上的一种趋势。
    但总体来看，RBAC没有让用户，角色和权限之间得到很好的整合，大多还是困在用户这里，试想，如果用户拥有的角色其实可以充当一个中许可证，一个用户有可以拥有多张许可证，这是理所当然的事，然能否再用一个对指定资源特殊的许可证呢？这就是我想的用户既然可以拥有角色，但同样也可以拥有指定的一些权限，这种而外分配的权限可以说是这个用户的特权（注意，不是角色，因为扩充角色特权那就让其他拥有此角色的用户同时拥有，这样的做法不是我所要讨论的扩展）。好了，如果形成这样的关系，就可以释放用户与角色之间的强捆绑了。
    但我还是觉得这样做是否合理，一个模块和多个操作，形成了一资源，这些资源是被保护的，如果添加模块，就要配置这些资源，但添加的模块又不可能在操作表名的动作都有，这样又要添加操作类型，权限验证的时候又需要到关系库中检查一下，其实，我觉得一个模块对应的操作不该由模块表和操作类型表配置来决定，因为他们可能是一个模块特有，这中间可能包括了权限继承关系，比如一个用户模块权限有read,add,modify,delete,query,all,注意这个ALL权限一旦有用，这会包含他所有的操作，有删除会有读取，这样当我们给与删除权限的时候其实read权限也就包含进去了，现在有一个管理员管理模块权限有read,add,modify,delete,query,reset_password,modify_password,all,定这些操作应为设计到管理员相关的操作，我们看这个模块比用户模块多了2个权限，这些特殊的权限应该是配置，这种权限继承关系也应该是定制的，网上发布的2的N此方整数组成的集合，素数分解等都是不错的权限继承办法。那是不是让我们在系统中扩展这些类就可以了列？是的，这样做的好处有：1.避免后台资源配置错误导致权限验证出现问题；2.获取管理员所有权限后直接在web层验证；3.可以设计自己的权限继承算法。
    说到这里，为什么说这个问题呢，因为我的主题是JAVA权限，JAVA已经提供了sucrity包，别忘了还有annotation。它可以帮我们条用指定方式的时候去用哪个定制的权限类去做验证。这样一来权限的问题可以得到灵活的扩充了，可能现在在这里一时无法说完整，但这个JAVA权限设计我已经开始设计，在设计完后希望和大家继续探讨。