Shiro

简述 Shiro 的3个核心组件

1.Subject
主体，代表当前‘用户’ 。这个用户不一定是一个具体的人与当前应用交互的任何东西都是Subject,如网络爬虫，机器人等；即一个抽象概念；所有Subject都绑定到SecurityManager,与Subject的所有交互都会委派给SecurityManager;可以把Subject认为是一个门面；SecurityManager才是实际的执行者

2.SecurityManager
安全管理器；协调内部各个安全组件之间的交互，且它管理者所有Subject;可以看出它是Shiro的核心，它负责与后面介绍的其它组件进行交互，可以把它看成DispathcherServlet前端控制器

3.Realms
Realms在Shiro和用户的应用程序之间扮演着桥梁和连接器的作用。当需要验证或者授权的时候，Shiro从一个或者多个配置的Realms中查找。

这种情况下，Realm是一个安全的DAO，它封装了具体数据库连接的细节，当Shiro需要的时候为Shiro提供需要的数据。当配置Shiro的时候，必须配置至少一个Realm来验证和授权。SecurityManager 可以配置多个Realm，至少需要一个。
也就是说SecurityManager要验证用户身份，那么它需要从Realm获取相应的用户进行比较以确定用户身份是否合法；也需要从Realm得到用户相应的角色/权限进行验证用户是否能进行操作。

SecurityManager有哪些部分组成
（1）Authenticator
认证器,负责主体认证的,这是一个扩展点,如果用户觉得Shiro默认的不好,可以自定义实现;其需要认证策略( Authentication Strategy) , 即什么情况下算用户认证通过了;

（2）Authorizer
授权器,或者访问控制器,用来决定主体是否有权限进行相应的操作;即控制着用户能访问应用中的哪些功能;

（3）SessionManager
Shiro抽象出来的一个自己的Session，用来管理主体与应用之间交互的数据;

（4）CacheManager
缓存控制器,来管理如用户、角色、权限等的缓存的;因为这些数据基本.上很少去改变,放到缓存中后可以提高访问的性能
还有sessionDao等

登录流程：

（1）首先调用Subject.login(token)进行登录，他会委托给SecurityManager
（2）SecurityManager负责真正的身份验证逻辑；它会委托给Authenticator进行身份验证；
（3）Authenticator会把相应的token传入Realm，从Realm获取身份验证信息，如果没有就返回认证失败，有的话就继续执行操作。

单点登录和授权流程：

（1）用户通过账号密码登录，验证密码和账号，验证成功会生成token令牌，返回给用户端，用户下一次执行操作时需要带上令牌。每一次请求成功都会更新令牌。
（2）当用户再次发起请求时，会被我们自己配置的过滤器拦截，拦截除了登录注册以外的请求，（拦截的规则可在ShrioConfig中配置）。
（3）然后将token令牌传给Util工具类获取新的令牌，并且进行登录认证和权限认证。
具体见：Springboot整合shiro+jwt

Shiro的四种权限控制方式

1）url 级别权限控制
2）方法注解权限控制
3）代码级别权限控制
4）页面标签权限控制

授权实现的流程

（1）什么是粗颗粒和细颗粒权限？
对资源类型的管理称为粗颗粒度权限控制，即只控制到菜单、按钮、方法，粗粒度的例子比如：用户具有用户管理的权限，具有导出订单明细的权限。对资源实例的控制称为细颗粒度权限管理，即控制到数据级别的权限， 比如：用户只允许修改本部门的员工信息，用户只允许导出自己创建的订单明细。
总结：
粗颗粒权限：针对url链接的控制。
细颗粒权限：针对数据级别的控制
比如：查询用户权限。
卫生局可以查询所有用户。
卫生室可以查询本单位的用户。
通常在service中编程实现。

（2）粗颗粒和细颗粒如何授权？
对于粗颗粒度的授权可以很容易做系统架构级别的功能，即系统功能操作使用统一的粗颗粒度的权限管理。 对于细颗粒度的授权不建议做成系统架构级别的功能，因为对数据级别的控制是系统的业务需求，随着业务需求的变更业务功能变化的可能性很大，建议对数据级别的权限控制在业务层个性化开发，比如：用户只允许修改自己创建的商品信息可以在service接口添加校验实现，service接口需要传入当前操作人的标识，与商品信息创建人标识对
比，不一致则不允许修改商品信息。
粗颗粒权限：可以使用过虑器统一拦截url。
细颗粒权限：在service中控制，在程序级别来控制，个性化 编程