关于用户，角色和权限的一点体会

本人从事j2ee的开发三年了，见过很多权限参考模型。我感觉虽然很多人可以做出一套权限管理模块，但是真正做得好的并不多（吐槽一下。我自己也没做出优秀的东西）。其中有部分人对权限管理模块不是很清楚，还有一部分是做出来的都权限参考模型实现能力不强。我个人觉得要做一个好的权限参考模型出来。首先要对权限参考模型的概念和原理有深刻的理解。然后有个好的设计和实现。这边我将自己的几年的工作感想写出来给大家分享一下。
权限参考模型有三个主要的概念：用户 角色 权限
用户：是在一个业务逻辑中存在的实体。是动作的发出者
角色：是一些具有共性的用户组的集合（这个集合是可以为空的）
权限：执行一系列动作的集合。简单的说就是业务操作的集合
这边就有几个问题了
1 用户和角色之间是什么关系？
2 角色分为什么类型？
3 角色和部门之前是什么关系？
4 角色和权限之间的关系？
5 用户和权限之间是什么关系？
这5个问题是这三年来一只在思考的问题。下面我将一个一个给大家分析
用户和角色之间是多对多的关系。也就是说一个用户可能属于几个角色。一个角色可以拥有很多用户。下面我们来分析第二个问题。角色大致可以分为几种类型。也许有人很奇怪，怎么角色还要分类型。我想跟大家说的是。角色真的要分类型，一般是分为管理角色和业务角色，管理角色一般是控制系统本身的权限。具体的说系统权限包括人员的添加。部门的创建。角色的创建等；
业务角色就是具体的操作权限。如果订单管理，销售管理。财务管理等为什么要这么分呢。结合我三年的经验我发现现在很多大型的企业特别是我工作的金融行业。他们的管理和业务操作区分很明显，如果一个管理员既能控制管理又能控制业务，那是一件多么恐怖的事情。下面我们接着第三个问题的讨论角色和部门之间是什么关系，也许有人问角色和部门有说没关系，经过我这三年的经验。我想跟大家说，角色和部门之间是有关系。我记得我之前有一个项目是这样的需求。如果一个总部的人登录系统。他点击一个操作。比如说查看订单。这个时候他就只能看到他们部门和子部分的数据。如果我们的角色和部门没关系。那么真的是一件很复杂的事情。当然我是将一个角色和部门做了关联。我们根据角色所属的部门就可以判断。当前用户可以查看那些部门的数据。角色和权限之间也是多对多的关系。下面我们重点分析用户和权限之间的关系。也许有人要问。不是有角色吗。怎么又直接让用户和权限扯上关系呢。事实上一套完整的权限参考模型就需要。我之前就碰到这么一个客户。他就提出创建一个用户。然后就要直接可以分配权限。我们告诉他可以先创建一个角色。然后将这个用户添加到这个角色，但是他非要直接分配。大家也知道我们做程序的。特别是那些大客户，我们只能尽量的满足。这个时候就产生了一系列新的问题了。首先用户要分为管理和业务类型。这样可以分配对应的权限。假如一个客户拥有一些权限同时将这个用户分配一个角色。这个用户所拥有的权限比这个角色拥有的多。简单来说，就是说用户分配的权限和这个角色拥有的权限不一样。这个时候怎么办？是以用户拥有的权限为主还是以角色拥有的权限为主？我个人的看法是以个人拥有的为主，下面我来说说我的想法。角色是将一些有共性的用户组成集合。但是这些用户之间必然有差异性，角色不具备原子性。用户具备原子性，当用户直接分配了权限的时候就代表当前用户的差异性。只有原子性的用户才能体现访问这个规则的正确性。
我们接着来分析第二个大的问题：allow和deny的优先级。就是允许和拒绝的优先级哪个级别高一些。由于一些用户具有多个角色。但是有些角色是允许访问，有些角色是禁止访问。这个时候怎么办？我目前采用的做法是取这些角色拥有权限的交集。也就是说拒绝的权限高于允许正是用户角色的复杂性，所以在没有足够证据证明“里面的有些角色被拒绝但实际上这个用户不应该拒绝”的情况下，应该先把这个用户拒绝掉。这也是出于安全性的考虑。