shiro相关概念的理解以及用户认证的相关操作
什么是shiro?
shiro是apache的一个开源框架，是一个权限管理的框架，实现用户认证、用户授权。shiro不仅可以实现 web应用的权限管理，还可以实现c/s系统，分布式系统权限管理，shiro属于轻量框架，越来越多企业项目开始使用shiro。使用shiro实现系统的权限管理，有效提高开发效率，从而降低开发成本。
什么是用户认证和用户授权？
用户认证：用户认证，用户去访问系统，系统要验证用户身份的合法性。最常用的用户身份验证的方法。
用户认证流程：
subject：主体，理解为用户,可能是程序，都要去访问系统的资源，系统需要对subject进行身份认证。
principal：身份信息，通常是唯一的，一个主体还有多个身份信息，但是都有一个主身份信息（primary principal）
credential：凭证信息，可以是密码 、证书、指纹。
总结：主体在进行身份认证时需要提供身份信息和凭证信息
用户授权：用户授权，简单理解为访问控制，在用户认证通过后，系统对用户访问资源进行控制，用户具有资源的访问权限方可访问。
授权流程：
授权的过程理解为：who对what(which)进行how操作。
who：主体即subject，subject在认证通过后系统进行访问控制。
what(which)：资源(Resource)，subject必须具备资源的访问权限才可访问该 资源。资源比如：系统用户列表页面、商品修改菜单、商品id为001的商品信息。
资源分为资源类型和资源实例：
系统的用户信息就是资源类型，相当于java类。
系统中id为001的用户就是资源实例，相当于new的java对象。
how：权限/许可(permission) ，针对资源的权限或许可，subject具有permission访问资源，如何访问/操作需要定义permission，权限比如：用户添加、用户修改、商品删除。
权限模型
主体（账号、密码）
资源（资源名称、访问地址）
权限（权限名称、资源id）
角色（角色名称）
角色和权限关系（角色id、权限id）
主体和角色关系（主体id、角色id）
如下图：
通常企业开发中将资源和权限表合并为一张权限表，如下：
资源（资源名称、访问地址）
权限（权限名称、资源id）
合并为：
权限（权限名称、资源名称、资源访问地址）
上图常被称为权限管理的通用模型，不过企业在开发中根据系统自身的特点还会对上图进行修改，但是用户、角色、权限、用户角色关系、角色权限关系是需要去理解的。
权限管理解决方案
什么是粗粒度和细粒度权限
粗粒度权限管理，对资源类型的权限管理。资源类型比如：菜单、url连接、用户添加页面、用户信息、类方法、页面中按钮。。
粗粒度权限管理比如：超级管理员可以访问户添加页面、用户信息等全部页面。
部门管理员可以访问用户信息页面包括 页面中所有按钮。
细粒度权限管理，对资源实例的权限管理。资源实例就资源类型的具体化，比如：用户id为001的修改连接，1110班的用户信息、行政部的员工。
细粒度权限管理就是数据级别的权限管理。
细粒度权限管理比如：部门经理只可以访问本部门的员工信息，用户只可以看到自己的菜单，大区经理只能查看本辖区的销售订单。。
粗粒度和细粒度例子：
系统有一个用户列表查询页面，对用户列表查询分权限，如果粗颗粒管理，张三和李四都有用户列表查询的权限，张三和李四都可以访问用户列表查询。
进一步进行细颗粒管理，张三（行政部）和李四(开发部)只可以查询自己本部门的用户信息。张三只能查看行政部 的用户信息，李四只能查看开发部门的用户信息。细粒度权限管理就是数据级别的权限管理。
如何实现粗粒度和细粒度权限管理
粗粒度权限管理比较容易将权限管理的代码抽取出来在系统架构级别统一处理。比如：通过springmvc的拦截器实现授权。
如何实现细粒度权限管理？
对细粒度权限管理在数据级别是没有共性可言，针对细粒度权限管理就是系统业务逻辑的一部分，如果在业务层去处理相对比较简单，如果将细粒度权限管理统一在系统架构级别去抽取，比较困难，即使抽取的功能可能也存在扩展不强。
建议细粒度权限管理在业务层去控制。
比如：部门经理只查询本部门员工信息，在service接口提供一个部门id的参数，controller中根据当前用户的信息得到该 用户属于哪个部门，调用service时将部门id传入service，实现该用户只查询本部门的员工。
Shiro架构
subject：主体，可以是用户也可以是程序，主体要访问系统，系统需要对主体进行认证、授权。
securityManager：安全管理器，主体进行认证和授权都 是通过securityManager进行。
authenticator：认证器，主体进行认证最终通过authenticator进行的。
authorizer：授权器，主体进行授权最终通过authorizer进行的。
sessionManager：web应用中一般是用web容器对session进行管理，shiro也提供一套session管理的方式
SessionDao：通过SessionDao管理session数据，针对个性化的session数据存储需要使用sessionDao。
cache Manager：缓存管理器，主要对session和授权数据进行缓存，比如将授权数据通过cacheManager进行缓存管理，和ehcache整合对缓存数据进行管理。
realm：域，领域，相当于数据源，通过realm存取认证、授权相关数据。
注意：在realm中存储授权和认证的逻辑(在自定义realm中，realm的类继承了AuthorizingRealm，同时也继承了认证和授权的方法，可以实现认证授权逻辑的编写)
cryptography：密码管理，提供了一套加密/解密的组件，方便开发。比如提供常用的散列、加/解密等功能。比如 md5散列算法。
Shiro认证
shiro-first.ini
通过此配置文件创建securityManager工厂
shiro-first.ini里的内容，配置数据
进行用户登录的测试代码：
执行流程：
1.通过ini配置文件创建securityManager
2.将securityManager设置在当前的运行环境中，用到了SecurityUtils，也是通过SecurityUtils来获取subject主体类
3.调用subject.login方法主体提交认证，提交的是token
4.securityManager进行认证，securityManager最终由ModularRealmAuthenticator进行认证
5.ModularRealmAuthenticator调用IniRealm（给realm传入token）去ini配置文件中查询用户信息
6.IniRealm根据输入的token（UsernamePasswordToken）从shiro-first.ini文件中查询用户信息，根据账号查询用户信息（账号和密码）
若查询到用户信息，就给ModularRealmAuthenticator返回用户信息（账户和密码）
若查询不到，就给ModularRealmAuthenticator返回null
7.ModularRealmAuthenticator接收IniRealm返回AuthenticationInfo信息
若返回的认证信息不是null（说明IniRealm找到了用户），对IniRealm返回用户密码（在ini文件中存在）和 token中的密码 进行对比，如果不一致抛出异常（org.apache.shiro.authc.IncorrectCredentialsException）
若返回的信息是Null，ModularRealmAuthenticator抛出异常（org.apache.shiro.authc.UnknownAccountException）
小结：
ModularRealmAuthenticator作用进行认证，需要调用realm查询用户信息（在数据库中存在用户信息）
ModularRealmAuthenticator进行密码对比（认证过程）。
realm：需要根据token中的身份信息去查询数据库（入门程序使用ini配置文件），如果查到用户返回认证信息，如果查询不到返回null。
自定义realm
将来实际开发需要realm从数据库中查询用户信息。
realm接口
自定义realm继承AuthorizingRealm实现代码：
配置realm
需要在shiro-realm.ini配置realm注入到securityManager中。
测试：
散列算法
通常需要对密码 进行散列，常用的有md5、sha，对md5密码，如果知道散列后的值可以通过穷举算法，得到md5密码对应的明文。
建议对md5进行散列时加salt（盐），进行加密相当 于对原始密码+盐进行散列。
正常使用时散列方法：
在程序中对原始密码+盐进行散列，将散列值存储到数据库中，并且还要将盐也要存储在数据库中。
如果进行密码对比时，使用相同 方法，将原始密码+盐进行散列，进行比对。
md5散列测试程序
自定义realm支持散列算法
需求：实际开发时realm要进行md5值（明文散列后的值）的对比。
新建realm(CustomRealmMd5)
在realm中配置凭证匹配器
以上就是shiro的用户认证相关操作，下一章将就shiro的用户授权进行操作讲解！
