医药采购系统平台第4天02：用户管理模块的权限管理&本系统的权限管理模型&用户授权流程&在原型系统中使用第三方SSO系统进行权限分配的演示&第三方的SSO系统与本系统的集成&session接口规范

如果想要获取相关的源码，笔记，和相关工具，关注我并私信！！！

---

一 用户管理模块之用户授权（又称权限管理，难点）

权限管理功能不是我们开发的，是使用的是第三方的SSO单点登录系统。我们要做的是如果把SSO系统接入到医药管理系统中，

然后，根据SSO系统提供的功能进行授权！

简单说，原系统是走的第三方SSO单点登录系统进行的认证和授权的功能！

而作为教学，我们只是实现了认证，而对于授权---->我们会把SSO系统接入到医药管理系统中，并设计出相同的9张表，从而进行功能的授权！

强调一遍：权限管理指的是用户授权，而拦截器不属于权限管理的范畴

1 需求概述

权限管理，一般指根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源!

注意：这里的权限管理其实就是指用户授权！拦截器是不属于权限管理的范畴！

当使用指定用户--->使用荥阳市卫生局身份来登录系统后，就应该显示出左侧的菜单（例如：下图的用户管理菜单），该菜单也可以称为菜单权限！

那么，就必须具备菜单内所有的操作权限！

简单说就是点击“用户管理”链接后，那么在下面页面的右半部分的所有链接，例如“添加”、“修改”、“删除”、“查询”等等就都具有操作的权限了！

否则，如果你给了该用户“用户管理”的操作连接后又不给该用户“添加”、“修改”、“删除”、“查询”等等链接操作权限的话，那岂不可笑？？？

如下图所示：

对操作菜单、操作权限等进行控制，从而满足系统安全需要。

权限的分配：是指根据用户的需求给不同的用户授于权限，这个过程就叫做用户授权。 

例如：“用户管理”这个菜单就只能给卫生局这个角色来使用的，其他的角色是不可以使用！

并且，既然“用户管理”这个菜单就给了卫生局这个角色来使用了，那么在页面的右侧的“添加”、“修改”、“删除”........等操

作也必须相应的被授予卫生局这个角色！

权限管理：从某种意义上说：权限管理就是用户授权！

记住：拦截器是不属于权限管理的范畴！！！！！！！

权限就是资源.

2 权限管理的通用设计模型

通用的数据模型只有5张表！如下图：

通用的数据模型只有5张表！

3 本系统的权限管理模型（重点）

3.1 权限管理模型的9张表

本系统的权限管理使用的是第三方的单点登录系统（也可以称为：用户授权系统），该单点登录系统对多个系统中的每个用户授权的功能都进行了封装，

单独的集成到了一个权限管理系统中，优点：这样可以节省开发成本，可以重复利用。

但是，作为教学，把用户授权的功能集成到了该药品采购系统中，也就是说：你只需要把“用户菜单”等等一些操作菜单，以及该菜单下的各种资源，例如：添加，修改..............等等操作的链接录入到如下的几张表中，然后还需要自己编写拦截器（虽然单点登录系统也有自己的拦截），来实现的！

同时，第三方的单点登录系统和本系统统一使用的都是如下的11张表：

确切的说，真正使用的是其中的9张表，分别是：

1）针对权限表进行拆分的4张表：

权限系统表BSS_SYS_SYSTEM、

权限部署节点表BSS_SYS_DEPLOYNODE、

权限菜单表BSS_SYS_MODELE、

权限操作表BSS_SYS_OPREATE！

2）以及4张关系表：

BSS_SYS_ROLESYS：角色系统关系表。该表作为角色表bss_sys_role和系统表bss_sys_system的中间表。

BSS_SYS_ROLENODE：角色节点关系表。该表作为角色表bss_sys_role和部署节点表bss_sys_deploynode的中间表。

BSS_SYS_ROLEMODULE：角色模块关系表。

BSS_SYS_ROLEOPERATE：角色操作关系表。

3）系统角色表BSS_SYS_ROLE.

这9张表在下面都会详细的叙述！

3.2 把一张权限表拆分为四张权限表

第三方的用户授权系统对上面的通用的设计模型中的5张表中的权限表进行了扩充！

1. 上图图解：其中，角色表是BSS_SYS_ROLE。

这里针对本医药采购系统（包括第三方授权系统）的权限表进行了拆分，拆分成了4张表。分别是：

权限系统表、权限菜单表、权限功能操作表、部署节点表，

这4张表都是本系统的资源，也是4张权限表。因此，也可以说权限就是资源，控制权限就是控制资源的操作！

下面分别做一一介绍：

1）BSS_SYS_SYSTEM：权限系统表

该表的主键字段是sysid。因为本系统是医药采购系统（当然，还可以是其他的系统）所以这里只有一条记录。当然，如果还有其他的系统，

那么都统一的使用该权限系统表BSS_SYS_SYSTEM来存储。

如下：

可以看到，该系统表中只有一条记录：医药采购系统！

在正常的开发中，该系统表中会有多个系统，例如：采购系统、招标系统...............等等。如果有多个系统，那么都会使用这一张系统表来存储！

目前还有医药采购系统！

2）BSS_SYS_DEPLOYNODE：权限部署节点表

该表中的字段sysid关联于系统表bss_sys_system中的主键字段sysid。

对于部署节点表BSS_SYS_DEPOLYNODE表，该表中存储的只有一个荥阳市医药采购系统。

而在正常的开发中，该表中可能还包括有郑州市医药采购系统、洛阳市医药采购系统.............................等等市级平台的多个采购系统，

只是目前只有一个荥阳市采购系统，表内容如下图：

该表在用户授权时使用，例如：赋予荥阳市医药采购系统具有“用户管理”的使用权限，而不允许用户访问洛阳市医药采购系统的“用户管理”权限！

3）BSS_SYS_MODULE：权限模块表（也称为权限菜单表）

也称为权限菜单表。主键字段是moduleid。因为它属于某个系统下的菜单表，如下图：

所以该表的sysid字段是外键字段，该外键字段关联于系统表BSS_SYS_SYSTEM的主键字段sysid。

如下图：

权限菜单表bss_sys_module表可以查看所有的一级菜单和二级菜单，它是一个树形结构。

该表的特性是：其中parentid字段值为0的表示一级菜单，而parentid的值中不为0的都是二级菜单，并且，所有的二级菜单中都有url链接地址。

深刻的理解该表的特性对于下面的sql语句的编写有很多的帮助！

外键关联如下图：

注意：该表是一个树形结构，可以看到：parentid字段关联自身表的主键字段moduleid。

4）BSS_SYS_OPERATE：权限功能操作表

该表记录了菜单表（模块表）下的各个操作的链接，链接都是以.action结尾的URL，如下图所示：

那么，BSS_SYS_OPERATE表的外键字段是moduleid，该外键字段关联模块表BSS_SYS_MODULE的主键moduleid字段！

注意：这4张表的创建是有关系和顺序的：在某个系统下的某个节点下的某个菜单下的操作链接！在编写sql语句时，也是按照该顺序进行关联的。

例如：在医药采购系统下的荥阳市医药采购平台下的用户管理菜单下的操作链接！

3.3 对权限角色关系表的扩充

在通用的权限管理模型中，角色表和权限表之间通过一张中间表---->角色权限关系表来进行关联的。

而本系统的权限管理由于对权限表拆分为4张权限表后，相应的，也需要分别为上面扩充的4张权限表分别创建4张关系表，

即上面的4张表都要和角色表BSS_SYS_ROLE分别建立关联关系。如下的4张中间关系表分别是：

1) BSS_SYS_ROLESYS角色系统关系表

角色系统关系表。该表作为角色表bss_sys_role和系统表bss_sys_system的中间表。

2) BSS_SYS_ROLENODE角色节点关系表

角色节点关系表。该表作为角色表bss_sys_role和部署节点表bss_sys_deploynode的中间表。

3) BSS_SYS_ROLEMODULE角色模块关系表

角色模块关系表。该表作为角色表bss_sys_role和模块表bss_sys_module表的中间表。

4) BSS_SYS_ROLEOPERATE角色操作关系表

角色操作关系表。该表作为角色表bss_sys_role和操作表bss_sys_operate表的中间表。

数据库中如下图：

根据表的命名可知：这4张关系表都是跟角色有关联的！

4 对角色表BSS_SYS_ROLE的优化

先说优化的结论吧：本系统省略了用户角色关系表！这是根据需求调研所得而做出的优化！

在大部分的权限管理系统中，通常的执行流程是：

首先用户登录系统，然后根据中间表--->用户角色关系表来使得用户查找到了角色，再根据角色权限关系表使得角色查找到了对应的权限。

但是，根据本系统的需求调研可知，角色表BSS_SYS_ROLE的rolename字段所表示的角色名称就是用户类型。

查看角色表BSS_SYS_ROLE，如下：

Rolename字段表示角色名称，

所以，不用为某个用户添加角色了，使用角色------->用户类型作了一个绑定，因此，可以省略用户角色关系表.

既然省略了用户角色关系表，那么如何根据用户来找角色呢？

绑定方法如下：

在数据字典明细表dictinfo中将角色id（roleid是角色表的id主键）存储在数据字典明细表dictinfo中的用户类型的remark字段中记录内。如下图：

其中，remark字段中的值是与角色表BSS_SYS_ROLE表中的主键字段ROLEID是一一对应的（这就是绑定的方法）！

5 用户授权流程（重点）

在通用的权限管理模型中，用户是通过用户角色关系表来找到角色的。那么，既然省略了用户角色关系表，那又如

何通过用户来查找到对应的角色呢？

步骤如下：（这个步骤在第6.2节中可以通过代码实现！）

用户登录后，就知道了该用户的类型groupid字段，通过获取用户类型所在的数据字典中的信息，从而拿用户类型对应的角色id ，然后再根据角色找到对应的权限（权限就是资源）了！

那么，权限中就包括了如下的权限资源，如下图：

简单说，就是查找如下的权限：

1）找用户对应的权限菜单(目的是为了在页面左侧的导航菜单中显示---->根据不同的用户显示不同的菜单，如上图)！

2）权限菜单显示出来后，还要找到登录的用户所对应的所有操作权限（如上图中的：添加按钮、修改链接、删除链接......

等等操作链接等等），然后就可以进行权限拦截校验！

权限拦截校验的方法：用户请求url时，如果url在权限操作内放行可以继续操作，如果不在这个范围内拦截，提示用

户：无此操作权限。通常提示的“无此操作权限”是给测试人员使用的！因为，既然用户登录了系统，点击“用户管

理”链接后所显示的页面中的所有链接必须给该用户使用了，这是顺理成章的事。

简单说，提示的“无此操作权限”基本是不存在的。因为你既然给用户菜单的操作权限，那么顺理成章菜单下的链接你也应该

让用户操作的！既然这样，为什么还要进行拦截校验呢？

对于这里拦截校验的意义还有一个：是为了避免不法分子通过在地址栏输入链接来进入系统从而操作资源。否则，如果不进行

权限拦截的校验，用户通过在地址栏中输入了例如“添加”链接的action，那么该系统就是一个很大的BUG。

因此，操作权限的拦截必须要校验！

一句话：对于页面中的任何链接都必须进行权限拦截的校验！