SaaS系统用户权限设计&RBAC&Shiro

用户、角色、资源、权限 

CREATE TABLE `co_department` (
 `id` varchar(40) NOT NULL,
`company_id` varchar(255) NOT NULL COMMENT '企业ID',
`parent_id` varchar(255) DEFAULT NULL COMMENT '父级部门ID',
`name` varchar(255) NOT NULL COMMENT '部门名称',
`code` varchar(255) NOT NULL COMMENT '部门编码',
`category` varchar(255) DEFAULT NULL COMMENT '部门类别',
`manager_id` varchar(255) DEFAULT NULL COMMENT '负责人ID',
`city` varchar(255) DEFAULT NULL COMMENT '城市',
`introduce` text COMMENT '介绍',
`create_time` datetime NOT NULL COMMENT '创建时间',
`manager` varchar(40) DEFAULT NULL COMMENT '部门负责人',
`update_time` datetime NOT NULL COMMENT '更新时间',
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

1.公共控制层

import org.springframework.web.bind.annotation.ModelAttribute;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
/**
* 公共controller
*     获取request，response
*     获取企业id，获取企业名称
*/
public class BaseController {
    protected HttpServletRequest request;
    protected HttpServletResponse response;
    @ModelAttribute
    public void setReqAndResp(HttpServletRequest request, HttpServletResponse response)
{
        this.request = request;
        this.response = response;
   }
    //企业id，（暂时使用1,以后会动态获取）
    public String parseCompanyId() {
        return "1";
   }
    public String parseCompanyName() {
        return "江苏播客教育股份有限公司";
   }
}

2 RBAC模型

2.1 什么是RBAC

        RBAC（全称：Role-Based Access Control）基于角色的权限访问控制，作为传统访问控制（自主访问，强制访 问）的有前景的代替受到广泛的关注。

        在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些 角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责 任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合 并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观 情况。 访问控制是针对越权使用资源的防御措施，目的是为了限制访问主体（如用户等） 对访问客体（如数据库资源等） 的访问权限。企业环境中的访问控制策略大部分都采用基于角色的访问控制（RBAC）模型，是目前公认的解决大 型企业的统一资源访问控制的有效方法。

2.2 基于RBAC的设计思路

基于角色的访问控制基本原理是在用户和访问权限之间加入角色这一层，实现用户和权限的分离，用户只有通过激 活角色才能获得访问权限。通过角色对权限分组，大大简化了用户权限分配表，间接地实现了对用户的分组，提高 了权限的分配效率。且加入角色层后，访问控制机制更接近真实世界中的职业分配，便于权限管理。

用户：角色：权限 多对多的关系。

即：一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的映射关系。在这种模型 中，用户与角色之间，角色与权限之间，一般者是多对多的关系。

3 SAAS-HRM中的权限设计

3.1 需求分析

 3.2 权限设计

 针对此种权限模型，其中权限究竟是属于菜单，按钮，还是API的权限呢？那就需要在设计数据库权限表的时候添 加类型加以区分（如权限类型 1为菜单 2为功能 3为API）。

3.3 表结构分析

 

1. 不需要区分哪些是操作，哪些是资源

2. 方便扩展，当系统要对新的东西进行权限控制时，我只需要建立一个新的资源表，并确定这类权限的权限类 型标识即可。

若想整明白权限，请先了解拦截器、过滤器！！！

Shiro

1、介绍

Apache Shiro是Java的一个安全框架。Shiro可以帮助我们完成：认证、授权、加密、会话管理、与Web集成、缓存等。其不仅可以用在 JavaSE环境，也可以用在 JavaEE 环境。

2、优点

• 易于理解的 Java Security API
• 简单的身份认证，支持多种数据源
• 对角色的简单的授权，支持细粒度的授权
• 不跟任何的框架或者容器捆绑，可以独立运行

3、特性

Authentication身份认证/登录，验证用户是不是拥有相应的身份
Authorization授权，即验证权限，验证某个已认证的用户是否拥有某个权限，即判断用户是否能做事情 SessionManagement会话管理，即用户登录后就是一次会话，在没有退出之前，它的所有信息都在会话中
Cryptography加密，保护数据的安全性，如密码加密存储到数据库，而不是明文存储
Caching缓存，比如用户登录后，其用户信息，拥有的角色/权限不必每次去查，提高效率
ConcurrencyShiro支持多线程应用的并发验证，即如在一个线程中开启另一个线程，能把权限自动传播过去
Testing提供测试支持
RunAs允许一个用户假装为另一个用户（如果他们允许）的身份进行访问
RememberMe记住我，这是非常常见的功能，即一次登录后，下次再来的话不用登录了

4、架构

Subject主体，代表了当前的“用户”，这个用户不一定是一个具体的人，与当前应用交互的任何东西都是Subject，如网络爬虫， 机器人等；即一个抽象概念；所有Subject都绑定到SercurityManager，与Subject的所有交互都会委托给SecurityManager；可以把Subject认为是一个门面；SecurityManager才是实际的执行者
SecurityManage安全管理器；即所有与安全有关的操作都会与SecurityManager交互；且它管理着所有Subject； 可以看出它是Shiro的核心，它负责与后边介绍的其他组件进行交互
Realm域，Shiro从Realm获取安全数据（如用户，角色，权限），就是说SecurityManager要验证用户身份， 那么它需要从Realm获取相应的用户进行比较以确定用户身份是否合法；也需要从Realm得到用户相应的角色/权限进行验证用户是否能进行操作；可以有1个或多个Realm，我们一般在应用中都需要实现自己的Realm
SessionManager如果写过Servlet就应该知道Session的概念，Session需要有人去管理它的生命周期，这个组件就是SessionManager
SessionDAODAO大家都用过，数据库访问对象，用于会话的CRUD，比如我们想把Session保存到数据库，那么可以实现自己的SessionDAO，也可以写入缓存，以提高性能
CacheManager缓存控制器，来管理如用户，角色，权限等的缓存的；因为这些数据基本上很少去改变，放到缓存中后可以提高访问的性能

应用代码通过Subject来进行认证和授权，而Subject又委托给SecurityManager； 我们需要给Shrio的SecurityManager注入Realm，从而让SecurityManager能得到合法的用户及其权限进行判断，Shiro不提供维护用户/权限，而是通过Realm让开发人员自己注入。

Shiro不会去维护用户，维护权限；这些需要自己去设计/提供；然后通过响应的接口注入给Shiro即可