RBAC权限管理

前言

RBAC（Role-Based Access Control,基于角色的访问控制），就是用户通过角色与权限进行关联。其实就是一个用户拥有多个角色，同样一个角色拥有多个用户，他们之间的关系为多对多的关系，在这里我们就抽出了一张第三张表用来记录用户和角色之间的关系。角色同样跟资源有关系，一个角色拥有多个资源，一个资源可以被多个角色使用，这样他们之间的关系同样也是多对多的关系，抽出一张第三张表。

用户组管理：

当用户的数量非常大的时候，要给系统每一个用户逐一授权，是一件很繁琐的事情，这样，我们就引入了用户组，每个用户组有多个用户，除了可给用户授权外，还可以给用户组授权，用户组有两个作用：第一，保持用户分组（当我们查找的时候，可以直接查找用户组，查看这个用户组下的用户）；第二，给用户分配角色可以减少工作量（不用逐一授权）。下面是用户组、用户、角色三者之间的关联关系。

不足点：

一般，在我们系统中，我们都清楚，如果引入了用户组，用户组并不能直接可以代替角色和用户的第三张表，又加了一张表，同样加了两张第三张表，分别是角色和用户组的第三张表和用户和用户组之间的第三张表，这样我们就增加了很多张表，在我看来，就得不偿失了，因此，我觉得我们完全可以用角色来替代用户组，换句话就是说，我们用角色来替代用户组，我们用角色来保持用户分组和批量分配角色来减少我们逐一分配角色的工作。因此，加上了用户组是否真正的简化了我们代码和逻辑，大家要想清楚了。

另外加上了用户组，我在权限的后台就要另外设计出用户组管理和分配用户组界面，在UI设计上来讲，无形中增加了用户的选择负担，用户在用这个权限系统给的时候，就会完全摸不到头脑的，他们根本不知道这个用户组管理是干什么用的，我们不能对用户进行培训才能用这个系统吧，所以，我觉得，界面上尽可能的减少让用户思考的界面，这样才能赢得用户，而这也是程序员最少关心的东西。

角色资源：

另外我们知道，给角色分配权限，是权限系统的另一大部分。在这一部分，一般来讲，一般的程序员会这样先给，权限表现为什么？对功能模块的操作，对上传文件的删改，菜单的访问，某个图片的可见性控制，都属于权限的范畴。我们粗略的一看，大部分都是对功能的实现了。我们先说一下关于功能方面，对权限系统的资源设置：

不足点：

从上面的图来讲，权限只是实现了一部分而已，功能部分，也就是说，我实现了根据不同的角色，所拥有的权限就都有了，但是，有没有想过，这样的设计仅仅只能满足部分的权限控制。为什么？我们举个例子，一个高校系统，里面有新生系统、基础系统、考评系统等等，我们要考虑的还有根据学生以新生的身份登录系统的时候，在9月份可以登录新生系统，如果到了10月份了，我们就不能登录这个系统了。同样考评系统也是这样的，当我们以考生的身份登录的时候，能看到我们要进行的考试，而非考试时间，我们只能进行模拟考试。这样，权限系统就不光光是功能控制，还有组织结构的控制（生科院的院长只能查看生科院的学生信息等）、时间控制（一定时间才会有的功能）、空间控制（在一定的ip段的时候才能使用）。

总结：

因此，我们在权限设计的时候，并不向我们想象中的那么简单，仅仅是简单的权限控制已经不能满足用户的需求了，我们需要通过更多的接口，来完善我们的权限控制。