Shiro是Apache的一个权限管理框架,鉴于很多人对权限管理的概念都不是很清楚,所以我在正式介绍Shiro前我会谈谈权限管理的概念。
1.权限管理
1.1什么是权限管理
只要有用户参与的系统一般都要有权限管理,权限管理实现对用户访问系统的控制,按照安全规则或者安全策略控制用户可以访问而且只能访问自己被授权的资源。权限管理包括用户认证和用户授权两部分
1.2用户认证
用户认证,用户去访问系统,系统要验证用户身份的合法性。最常用的用户身份验证的方法:1、用户名密码方式。2、指纹打卡机。3、基于证书验证方法。只有当系统验证用户身份合法,用户才可访问系统的资源。
1.2.1用户认证流程
1.2.2关键对象
subject:主体,理解为用户,可能是程序、网络爬虫等,都要去访问系统的资源,系统需要对subject进行身份认证。
principal:身份信息,通常是唯一的,一个主体还有多个身份信息,但是都有一个主身份信息(primary principal)。
credential:凭证信息,可以是密码 、证书、指纹。
总结:主体在进行身份认证时需要提供身份信息和凭证信息。
1.3用户授权
用户授权,简单理解为访问控制,在用户认证通过后(注意只有当用户认证通过后才能对用户进行授权),系统对用户访问资源进行控制,用户具有资源的访问权限方可访问。
1.3.1授权流程
1.3.2关键对象
授权的过程理解为:who对what(which)进行how操作。
who:主体即subject,subject在认证通过后系统进行访问控制。
what(which):资源(Resource),subject必须具备资源的访问权限才可访问该 资源。资源比如:系统用户列表页面、商品修改菜单、商品id为001的商品信息。资源分为资源类型和资源实例:系统的用户信息就是资源类型,相当于java类;系统中id为001的用户就是资源实例,相当于new的java对象。
how:权限/许可(permission) ,针对资源的权限或许可,subject具有permission访问资源,如何访问/操作需要定义permission,权限比如:用户添加、用户修改、商品删除。
1.3.3权限模型
对1.3.2节提到的主体、资源、权限通过数据模型表示,标准权限数据模型包括 :用户(账号和密码)、角色(角色名称)、权限(包括资源和权限)、用户角色关系(用户id、角色id)、角色权限关系(角色id、权限id)。如下图:
而通常企业开发中将资源表和权限表合并为一张权限表,如下图:
上图常被称为权限管理的通用模型,不过企业在开发中根据系统自身的特点还会对上图进行修改,但是用户、角色、权限、用户角色关系、角色权限关系是需要去理解的。
1.3.4分配权限
用户需要分配相应的权限才可访问相应的资源。权限是对于资源的操作许可。
通常给用户分配资源权限需要将权限信息持久化,比如存储在关系数据库中。
把用户信息、权限管理、用户分配的权限信息写到数据库(权限数据模型)。
1.3.5权限控制(授权的核心)
权限的控制分为基于角色的访问控制和基于资源的访问控制。
基于角色的访问控制:RBAC((role based access control)。比如:系统角色包括 :部门经理、总经理。(角色针对用户来划分)。
系统代码中的实现为:1
2
3
4
5//如果该user是部门经理则可以访问if中的代码
if(user.hasRole('部门经理')){
//系统资源内容
//用户报表查看
}
基于角色的访问控制出现的问题:角色针对人划分的,人作为用户在系统中属于活动内容,如果该 角色可以访问的资源出现变更,需要修改你的代码了,比如:需要变更为部门经理和总经理都可以进行用户报表查看,代码改为:1
2
3
4if(user.hasRole('部门经理') || user.hasRole('总经理') ){
//系统资源内容
//用户报表查看
}
可知基于角色的访问控制是不利于系统维护(可扩展性不强)。
而对于基于资源的访问控制:RBAC(Resource based access control)。因为资源在系统中是不变的,比如资源有:类中的方法,页面中的按钮。对资源的访问需要具有permission权限,代码可以写为:1
2
3
4if(user.hasPermission ('用户报表查看(权限标识符)')){
//系统资源内容
//用户报表查看
}
上边的方法就可以解决用户角色变更不用修改上边权限控制的代码。如果需要变更权限只需要在分配权限模块去操作,给部门经理或总经理增或删除权限。所以在实际开发中我们建议使用基于资源的访问控制实现权限管理。
1.4权限管理解决方案
1.4.1什么是粗粒度和细粒度权限
粗粒度权限管理:对资源类型的权限管理。资源类型比如:菜单、url连接、用户添加页面、用户信息、类方法、页面中按钮。粗粒度权限管理比如:超级管理员可以访问户添加页面、用户信息等全部页面。部门管理员可以访问用户信息页面包括 页面中所有按钮。
细粒度权限管理:对资源实例的权限管理。资源实例就资源类型的具体化,比如:用户id为001的修改连接,1110班的用户信息、行政部的员工。细粒度权限管理就是数据级别的权限管理。细粒度权限管理比如:部门经理只可以访问本部门的员工信息,用户只可以看到自己的菜单,大区经理只能查看本辖区的销售订单。
粗粒度和细粒度例子:系统有一个用户列表查询页面,对用户列表查询分权限,如果粗颗粒管理,张三和李四都有用户列表查询的权限,张三和李四都可以访问用户列表查询。
进一步进行细颗粒管理,张三(行政部)和李四(开发部)只可以查询自己本部门的用户信息。张三只能查看行政部 的用户信息,李四只能查看开发部门的用户信息。细粒度权限管理就是数据级别的权限管理。
1.4.2如何实现粗粒度和细粒度权限管理
如何实现粗粒度权限管理?
粗粒度权限管理比较容易将权限管理的代码抽取出来在系统架构级别统一处理。比如:通过springmvc的拦截器实现授权。
如何实现细粒度权限管理?
对细粒度权限管理在数据级别是没有共性可言,针对细粒度权限管理就是系统业务逻辑的一部分,如果在业务层去处理相对比较简单,如果将细粒度权限管理统一在系统架构级别去抽取,比较困难,即使抽取的功能可能也存在扩展不强。
建议细粒度权限管理在业务层去控制。比如:部门经理只查询本部门员工信息,在service接口提供一个部门id的参数,controller中根据当前用户的信息得到该 用户属于哪个部门,调用service时将部门id传入service,实现该用户只查询本部门的员工。
2.什么是Shiro
Apache Shiro是Java的一个权限管理框架,相比Spring框架中的权限管理框架Spring Security,Spring Security和Spring的依赖过于紧密,没有Shiro使用简单,而且Shiro不依赖Spring,它不仅可以实现web应用的权限管理,还可以实现c/s系统、分布式系统权限管理。
Shiro属于轻量框架,可以帮助我们完成:认证、授权、加密、会话管理、与Web集成、缓存等功能,所以越来越多企业项目开始使用Shiro。而且Shiro的API也是非常简单,其基本功能点如下图:
解释:
- Authentication:身份认证/登录,验证用户是不是拥有相应的身份。
- Authorization:授权,即权限验证,验证某个已认证的用户是否拥有某个权限;即判断用户是否能做事情,常见的如:验证某个用户是否拥有某个角色。或者细粒度的验证某个用户对某个资源是否具有某个权限。
- Session Manager:会话管理,即用户登录后就是一次会话,在没有退出之前,它的所有信息都在会话中;会话可以是普通JavaSE环境的,也可以是如Web环境的。
- Cryptography:加密,保护数据的安全性,如密码加密存储到数据库,而不是明文(所谓明文,就是我们输入的文字例如登录列表的用户名和密码)存储。
- Web Support:Web支持,可以非常容易的集成到Web环境。
- Caching:缓存,比如用户登录后,其用户信息、拥有的角色/权限不必每次去查,这样可以提高效率。
- Concurrency:shiro支持多线程应用的并发验证,即如在一个线程中开启另一个线程,能把权限自动传播过去。
- Testing:提供测试支持。
- Run As:允许一个用户假装为另一个用户(如果他们允许)的身份进行访问。
- Remember Me:记住我,这个是非常常见的功能,即一次登录后,下次再来的话不用登录了。
记住一点:Shiro不会去维护用户、维护权限,这些需要我们自己去设计/提供;然后通过相应的接口注入给Shiro即可。
接下来我们分别从外部和内部来看看Shiro的架构,对于一个好的框架,从外部来看应该具有非常简单易于使用的API,且API契约明确;从内部来看的话,其应该有一个可扩展的架构,即非常容易插入用户自定义实现,因为任何框架都不能满足所有需求。
3.Shiro架构
3.1从外部看Shiro架构
从外部看Shiro,即从应用程序的角度来观察如何使用Shiro完成工作。如下图Apache官网为我们提供的一张Shiro的架构图:
解释:应用代码直接交互的对象是Subject,也就是说Shiro的对外API核心就是Subject;图中每个API的含义:
- Subject:主体,代表了当前“用户”,这个用户不一定是一个具体的人,与当前应用交互的任何东西都是Subject,如网络爬虫,机器人等;即一个抽象概念;所有Subject都绑定到SecurityManager,与Subject的所有交互都会委托给SecurityManager;可以把Subject认为是一个门面;SecurityManager才是实际的执行者。
- SecurityManager:安全管理器;即所有与安全有关的操作都会与SecurityManager交互;且它管理着所有Subject;可以看出它是Shiro的核心,它负责与后边介绍的其他组件进行交互,如果学习过SpringMVC,你可以把它看成DispatcherServlet前端控制器。
- Realm:域,Shiro从从Realm获取安全数据(如用户、角色、权限),就是说SecurityManager要验证用户身份,那么它需要从Realm获取相应的用户进行比较以确定用户身份是否合法;也需要从Realm得到用户相应的角色/权限进行验证用户是否能进行操作;可以把Realm看成DataSource,即安全数据源。
也就是说对于我们而言,最简单的一个Shiro应用都是经过如下步骤:
1、应用代码通过Subject来进行认证和授权,而Subject又委托给SecurityManager。
2、我们需要给Shiro的SecurityManager注入Realm,从而让SecurityManager能得到合法的用户及其权限进行判断。
从以上也可以看出,Shiro不提供维护用户/权限,而是通过Realm让开发人员自己注入。
3.2从内部看Shiro架构
架构图如下:
分析:
- Subject:主体,可以看到主体可以是任何可以与应用交互的“用户”。
- SecurityManager:相当于SpringMVC中的DispatcherServlet或者Struts2中的FilterDispatcher;是Shiro的心脏;所有具体的交互都通过SecurityManager进行控制;它管理着所有Subject、且负责进行认证和授权、及会话、缓存的管理。
- Authenticator:认证器,负责主体认证的,这是一个扩展点,如果用户觉得Shiro默认的不好,可以自定义实现;其需要认证策略(Authentication Strategy),即什么情况下算用户认证通过了。
- Authrizer:授权器,或者访问控制器,用来决定主体是否有权限进行相应的操作;即控制着用户能访问应用中的哪些功能。
- Realm:可以有1个或多个Realm,可以认为是安全实体数据源,即用于获取安全实体的;可以是JDBC实现,也可以是LDAP实现,或者内存实现等等;由用户提供;注意:Shiro不知道你的用户/权限存储在哪及以何种格式存储;所以我们一般在应用中都需要实现自己的Realm。
- SessionManager:如果写过Servlet就应该知道Session的概念,Session呢需要有人去管理它的生命周期,这个组件就是SessionManager;而Shiro并不仅仅可以用在Web环境,也可以用在如普通的JavaSE环境、EJB等环境;所有呢,Shiro就抽象了一个自己的Session来管理主体与应用之间交互的数据;这样的话,比如我们在Web环境用,刚开始是一台Web服务器;接着又上了台EJB服务器;这时想把两台服务器的会话数据放到一个地方,这个时候就可以实现自己的分布式会话(如把数据放到Memcached服务器)。
- SessionDAO:DAO大家都用过,数据访问对象,用于会话的CRUD,比如我们想把Session保存到数据库,那么可以实现自己的SessionDAO,通过如JDBC写到数据库;比如想把Session放到Memcached中,可以实现自己的Memcached SessionDAO;另外SessionDAO中可以使用Cache进行缓存,以提高性能;
- CacheManager:缓存控制器,来管理如用户、角色、权限等的缓存的;因为这些数据基本上很少去改变,放到缓存中后可以提高访问的性能。
- Cryptography:密码模块,Shiro提高了一些常见的加密组件用于如密码加密/解密的。
到此Shiro的架构及组件就介绍完了,接下来我会总结关于如何使用这些组件。见下篇文章Shiro之实现认证
本篇文章参考:张开涛:跟我学Shiro之Shiro简介
正如孔老先生所言:你对看到的、学到的知识不加以整理,又怎么会融会贯通成为你自己的知识呢?
2018.3.19更
欢迎加入我的Java交流1群:659957958。
2018.4.21更:如果群1已满或者无法加入,请加Java学习交流2群:305335626 。
4.联系
If you have some questions after you see this article,you can tell your doubts in the comments area or you can find some info by clicking these links.