权限管理
1、权限管理的目的
- 安全性：防止误操作，人为破环，数据泄露。
- 责权明确：明确不同用户的不同权限和责任；通过系统权限，让不同系统权限的用户可以查看不同的系统；通过菜单，让拥有不同菜单权限让不同用户可以查看不同的页面；通按钮权限（接口权限），让拥有不同按钮权限的人可以操作不同的按钮。这是从操作层面保证数据的安全性。
- 数据隔离：不同的数据权限能看到及操作的数据不同，从可视化层面保证数据的让不同角色看到，从而保证数据的安全性。
2、权限管理的核心
1）用户-权限
人员少，功能固定，或者特别简单的系统。典型的是mysql权限管理。
img
2）RBAC模型（Role-Base Access Control）
RBAC是基于角色的访问控制。RABC的核心是用户，角色，权限，以及他们之间的关系。
在RBAC中，用户和角色相关联，角色和权限相关联。用户通过拥有相关的角色，进而也就拥有类角色相关联的权限。进而极大的简化了权限管理。
在一个组织中，角色是为了完成某种工作而创造出来的，用户则根据他的责任和权利被指派成相应的角色。同时，当用户责任和权利变化的时候。可以很容易的将用户的角色进行转化。角色可以根据新的需求、系统的合并等操作修改关联的权限列表，而权限也可以根据情况从某个角色中回收。角色和角色可以组成的级联关系，进而覆盖更广泛的场景。
RABC的关键是用户，角色，权限，以及他们之间的关系。用户和角色的关系叫做User Assignment；角色和权限的关系叫做Permission Assignment。他们之间的关系都是多对多的关系。
拥有相同权限的用户又可以划分出组的概念，组和用户都是和组织机构有关，但又不是组织结构。他们在概念上是不同的。组织机构是物理存在的，公司结构的抽象模型，包括部门，人员，职位。而权限模型是对抽象概念的描述。例如，可以有副经理这个组，这个组里面的人都拥有副经理的责权。引入组的概念，除了用于解决很多人拥有相同角色的问题外，还可以用来姐姐组织机构的另一种授权问题，比如，A部门人都可以查看A部门的的新闻，有了一个A部门对应的一个组，就可以直接授权给这个组了。
另外RBAC设计支持著名的三个原则：
最小权限原则：RBAC可以将角色配置成任务所需要的最小权限集合
责任分离原则：则可以通过调用相互独立、互斥的角色来共同完成敏感的任务，比如要求一个记账员，一个财务管理员共同参与同一个过账。
-
数据抽象原则：可以通过权限的抽象体现。比如财务操作借款、存款等这些抽象权限，而不是操作系统提供的读写执行权限
这些原创必须通过RBAC元部件地详细配置才能体现。
3、理想中的权限管理
1）角色级的权限管理
就是基于RBAC模型实现的权限管理。目前企业级项目使用的权限系统都是基于RBAC这种模型的，这种模型几乎能覆盖所有场景，同时能够满足需求的不断变化，许多临时的调整也能很好的应对。
基于RBAC模型实验的权限管理很好的完成了对全面关系的抽象，只需要根据实际场景做些不同的实现即可。相对直接对用户绑定权限，RBAC模型可以做更多的扩展。
2）功能级权限
那么什么是功能级权限和数据级权限呢？所谓的功能级权限，就是功能权限管理技术，一般就使用RBAC模型。目前RBAC模型也已经广泛的运用在各个系统，非常容易掌握。
功能级权限管理系统，会提供如下功能：
角色管理系统。由用户定角色，给角色赋予权限
用户角色管理界面，由用户给系统用户赋予角色
-
支持用户定义权限，这样新增功能的时候可以将需要保护的功能添加到系统。
功能级的权限，验证逻辑非常简单，查看该当前登录用户的角色是否包含该功能的权限，如果有则表示有权访问，否则表示无权访问。
3）数据级权限
目前数据级管理的领域一直没有统一的技术，大体上软件人员采用如下技术：
硬编码，就是将这种逻辑以if else的形式与业务代码耦合在一起，这种情况居多
使用规则引擎，也有一些企业将这种逻辑以规则形式提出来，并使用规则引擎解析规则
-
第三方专业软件
硬编码的形式的弊端是非常显然的，耦合性强，难以测试，系统组件复用率低，系统后期改动代价非常大，牵一发而动全身；使用规则引擎可以解决很多问题，学习难度尚可，但规则引擎并不是专业用于权限管理的，所以对于一些复杂的权限管理就显得力不从心。
因此理想中的前沿 管理是能同时实现功能级权限和数据级权限的。
4）简单，易操作，能够应付各种需求
这里我们主要希望所有涉及到权限相关的都能有相关的页面来查看和操作，同时如果能提供一个页面，能查到一个用户当前的权限列表会更好，这样所有权限相关的都可以在页面上看到，一目了然。
那么我们需要哪些页面呢？权限操作页面它主要分两类：
- 基础数据的配置页面，包括权限管理界面，角色管理界面，用户管理界面。
- 权限管理界面里，通常我们会引入权限模块的概念，将权限按模块划分开来，方便管理。同时支持对权限模块的增删改查，对权限的增删改查。
- 角色权限管理界面相对容易一些，做好角色的增删改查即可。
- 用户管理界面除了做好用户的增删改查外，为了扩展需要，需要页面能完成对组的概念的实现。就相当于，把一个人放到他的部门里，然后这个部门也支持增删改查。除了这些基本的功能外，我们可能还希望能看到部门和权限模块是能支持数型结构展开的。涉及到用户角色权限等的更新，我们会希望可以查看他们的更新日志， 必要的时候还可以对其进行恢复。
- 权限关系的维护界面，包括角色和权限关系的维护界面和角色和用户关系的维护界面。这部分是最核心的页面，我们会希望查看某个角色已经配置的权限，某个角色已经包含了用户，然后允许在页面上做一些操作。
4、权限开源项目
目前比较流行的开源项目有两个，spring security和apache shiro。
1）Shiro
Apache Shiro是一个强大且易用的Java安全框架,能够非常清晰的处理认证、授权、管理会话以及密码加密。使用Shiro的易于理解的API,您可以快速、轻松地获得任何应用程序,从最小的移动应用程序到最大的网络和企业应用程序。
特点
- 易于理解的 Java Security API；
- 简单的身份认证（登录），支持多种数据源（LDAP，JDBC，Kerberos，ActiveDirectory 等）；
- 对角色的简单的签权（访问控制），支持细粒度的签权；
- 支持一级缓存，以提升应用程序的性能；
- 内置的基于 POJO 企业会话管理，适用于 Web 以及非 Web 的环境；
- 异构客户端会话访问；
- 非常简单的加密 API；
- 不跟任何的框架或者容器捆绑，可以独立运行。
2）Spring Security
Spring Security 主要实现了Authentication（认证，解决who are you? ） 和 Access Control（访问控制，也就是what are you allowed to do？，也称为Authorization）。Spring Security在架构上将认证与授权分离，并提供了扩展点。它是一个轻量级的安全框架，它确保基于Spring的应用程序提供身份验证和授权支持。**它与Spring MVC有很好地集成** ，并配备了流行的安全算法实现捆绑在一起。
特点
shiro能实现的，Spring Security 基本都能实现，依赖于Spring体系，但是好处是Spring全家桶的亲儿子，集成上更加契合，在使用上，比shiro略负责。
3）两者对比
Shiro比Spring Securi ty更容易使用，也就是实现上简单一些，同时基本的授权认证Shiro也基本够用
Spring Security社区支持度更高，Spring社区的亲儿子，支持力度和更新维护上有优势，同时和Spring这一套的结合较好。
Shiro 功能强大、且 简单、灵活。是Apache 下的项目比较可靠，且不跟任何的框架或者容器绑定，可以独立运行。
如果开发的项目是Spring这一套，用Spring Security我觉得更合适一些，他们本身就是一套东西，顺畅，可能略微复杂一些，但是学会了就是自己的。如果开发项目比较紧张，Shiro可能更合适，容易上手，也足够用，Spring Security中有的，Shiro也基本都有，没有的部分网上也有大批的解决方案。
如果项目没有使用Spring这一套，不用考虑，直接Shiro。
**同时要考虑团队成员的技术栈，更加熟悉使用哪个，在选型上，也要尽量避免给同行增加不必要的学习成本！**
参考自[在 SpringBoot 项目中，Spring Security 和 Shiro 该如何选择？ - 云+社区 - 腾讯云 (tencent.com)](https://cloud.tencent.com/developer/article/1819901)
5、权限认证方式
1、账号密码认证登陆
普通的账号密码登陆，一般情况会将用户信息存储到数据库，并对密码进行加密，加密方式有hash，md5，des1/des2/des3，rsa等国际加密方式，也有sm1、sm2等国密加密方式。
2、cas认证登陆
img
中央认证服务器和客户端，通过ticket，cookie和session进行认证登陆。
可以参考：cas服务器搭建 - 小不点丶 - 博客园 (cnblogs.com)
