securitymanager

Shiro的设计目标就是让应用程序的安全管理更简单、更直观。 软件系统一般是基于用户故事来做设计。也就是我们会基于一个客户如何与这个软件系统交互来设计用户界面和服务接口。比如，你可能会说：“如果用户登录了我们的系统，我就给他们显示一个按钮，点击之后可以查看他自己的账户信息。如果没有登录，我就给他显示一个注册按钮。” 上述应用程序在很大程度上是为了满足用户的需求而编写的，即便这个“用户”不是人，而是一个其他的软件系统。你仍然是按照谁当前正在与你的系统交互的逻辑来编写你的逻辑代码。 Shiro的设计已经考虑到以上这些用户安全的概念。 总览 在最顶层，Shiro的架构有3个主要概念：Subject、SecurityManager和Realms。下图展示了这几个组件之间的交互，下面我们会逐一介绍这些概念： #，Subject，正如我们在 教程 中所说，Subject其实代表的就是当前正在执行操作的用户，只不过因为“User”一般指代人，但是一个“Subject”可以是人，也可以是任何的第三方系统，服务账号等任何其他正在和当前系统交互的第三方软件系统。 所有的Subject实例都被绑定到一个SecurityManager，如果你和一个Subject交互，所有的交互动作都会被转换成Subject与SecurityManager的交互。 #，SecurityManager

提到Shiro，不得不先介绍RBAC介绍 RBAC介绍： 　　RBAC是基于角色的访问控制（Role-Based Access Control ）在 RBAC 中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。这样管理都是层级相互依赖的，权限赋予给角色，而把角色又赋予用户，这样的权限设计很清楚，管理起来很方便。 在RBAC模型里面，有3个基础组成部分，分别是：用户、角色和权限。 RBAC通过定义角色的权限，并对用户授予某个角色从而来控制用户的权限，实现了用户和权限的逻辑分离，极大地方便了权限的管理，在讲解之前，先介绍一些名词： User（用户）：每个用户都有唯一的UID识别，并被授予不同的角色 Role（角色）：不同角色具有不同的权限 Permission（权限）：访问权限 用户-角色映射：用户和角色之间的映射关系 角色-权限映射：角色和权限之间的映射 权限管理：（包含两部分：用户认证，用户授权） 　　只要有用户参与的管理系统一般都有权限管理，权限管理实现对用户访问系统的控制，按照安全规则实现用户可以访问自己被授权的资源。 用户认证: 关键对象： subject：主体，理解为用户,可能是程序，都要去访问系统的资源，系统需要对subject进行身份认证。 principal：身份信息，通常是唯一的，一个主体还有多个身份信息

1. Authentication ：所谓的用户的认证就是用户登录。 需要提供身份和凭证给shiro。也就是subject中的标志属性，唯一标志subject。(你提供的信息一定是能够唯一标识subject的，比如：身份证号、手机号、邮箱… …) 解释 ： Credentials 凭证：是指被Subject知道的密码值。可以是密码，也可以是数字证书等。 Principals/Credentials最常见的组合：用户名/密码。 在shrio中通常使用username、password、Token来指定身份和凭证信息。 3.代码实现 1.新建测试类 AuthenticationTest 备注：别忘记提前导入shiro的Maven依赖哦 新建shiro.ini文件 ### root是用户。， 123456 是密码 ### [ users ] 是配置用户——可以有多个用户 [ users ] root = 123456 代码编写 package shiroTest ; /** * @title: AuthenticationTest * @projectName sixBox * @description: TODO * @author Lenovo * @date 2019/12/2317:51 */ import org . apache . shiro . SecurityUtils

1.maven引包 1 <dependency> 2 <groupId>org.apache.shiro</groupId> 3 <artifactId>shiro-spring</artifactId> 4 <version>1.2.5</version> 5 </dependency> 6 <dependency> 7 <groupId>org.apache.shiro</groupId> 8 <artifactId>shiro-ehcache</artifactId> 9 <version>1.2.5</version> 10 </dependency> 2.创建数据库 shiro一般需要5张表：3张实体表user,role,permission（一对一），2张关系映射表user-role,role-permission（一对多） 大致结构: user:id name password ... role : id name permission:id name user-role:uid rid role-permission:rid pid 配置文件和model，mapper，service等构建过程不赘述，能实现查询数据库即可 3.创建抽象类 AbstractUserRealm package com.tqh.demo.config; import com.tqh

公司新项目用的是shiro做权限控制，一直说写一篇shiro的文章，一直拖着没写。马上过年了， 这债该还了呀。。。 项目基于springboot(2.1.7.RELEASE) + mybatis-plus(3.2.0) + shiro-redis（3.2.3） 知识储备 原理参考：1、 shiro框架详解。 2、 Shiro权限管理框架详解 。 有些名词还是得先了解： Subject：主体，可以看到主体可以是任何可以与应用交互的“用户”； SecurityManager ： 安全管理器，对全部的subject进行安全管理，它是shiro的核心，负责对所有的subject进行安全管理。通过SecurityManager可以完成subject的认证、授权等，实质上SecurityManager是通过Authenticator进行认证，通过Authorizer进行授权，通过SessionManager进行会话管理等; FilterDispatcher；是 Shiro 的心脏；所有具体的交互都通过 SecurityManager 进行控制；它管理着所有 Subject、且负责进行认证和授权、及会话、缓存的管理。 Authenticator（authc）：认证器，负责主体认证的，这是一个扩展点，如果用户觉得 Shiro 默认的不好，可以自定义实现；其需要认证策略（Authentication

先看下面的测试类及测试结果 @Test public void bufferTest ( ) { Subject subject = ShiroUtil . login ( "zhangsan" , "123456" ) ; subject . isPermitted ( "sys:user:list" ) ; subject . isPermitted ( "sys:user:list" ) ; subject . isPermitted ( "sys:user:list" ) ; } } 我们会发现授权完成运行了3次，这并不是我们想看到的。 为什么要使用缓存？ 在没有使用缓存的情况下，每发送一次请求都会调用一次doGetAuthorizationInfo方法来进行用户的授权操作，但是我们知道，一个用户具有的权限一般不会频繁的修改，也就是每次授权的内容都是一样的，所以我们希望在用户登录成功的第一次授权成功后将用户的权限保存在缓存中，下一次请求授权的话就直接从缓存中获取，这样效率会更高一些。 下面说几种缓存办法。 使用内置缓存 在shiro系列文章第一篇我们就已经提及到了 CacheManager(缓存管理器) ，这是shiro封装好的内置缓存器，现在我们来使用一下它。 看下我们的自定义的工具类 其实只要创建一个缓存管理器，并放入我们的安全管理器中就可以了。