权限设计对于系统来说是一套资源防御系统,避免不同用户种类越权使用。这几天看了一些权限设计设计,但还是感觉他们似乎还是有点欠缺,首先我比较关注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权限设计我已经开始设计,在设计完后希望和大家继续探讨。
首先看第一种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权限设计我已经开始设计,在设计完后希望和大家继续探讨。