Apache Shiro [基础]

1、前言

     Apache Shiro是一个强大且易用的Java安全框架,可以完成认证、授权、加密、会话管理、与Web 集成、缓存等。对比Spring Security，没有Spring Security功能强大，但小而简单的Shiro。

2、特性

      可完成认证、授权、加密、会话管理、与Web集成、缓存等。

3、功能图

1）4大主要功能[four primary concerns]

     Authentication [ɔːˌθentɪˈkeɪʃn]：身份认证/登录，验证用户是不是拥有相应的身份；

     Authorization [ˌɔːθəraɪˈzeɪʃn]：授权，即权限验证，验证某个已认证的用户是否拥有某个权限；即判断用户是否能做事情，常见的如：验证某个用户是否拥有某个角色。或者细粒度的验证某个用户对某个资源是否具有某个权限；

     Session Manager：会话管理，即用户登录后就是一次会话，在没有退出之前，它的所有信息都在会话中；会话可以是普通JavaSE环境的，也可以是如Web环境的；

     Cryptography [krɪpˈtɑːɡrəfi]：加密，保护数据的安全性，如密码加密存储到数据库，而不是明文存储；

2）以下为辅助功能[some auxiliary features]

      Web Support：Web支持，可以非常容易的集成到Web环境；

      Caching：缓存，比如用户登录后，其用户信息、拥有的角色/权限不必每次去查，这样可以提高效率；

      Concurrency [kənˈkɚrənsi]：shiro支持多线程应用的并发验证，即如在一个线程中开启另一个线程，能把权限自动传播过去；

  Testing：提供测试支持；

   Run As：允许一个用户假装为另一个用户（如果他们允许）的身份进行访问；

   Remember Me：记住我，这个是非常常见的功能，即一次登录后，下次再来的话不用登录了。

4、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能得到合法的用户及其权限进行判断。

5、Shiro内部架构

      Subject：主体，可以看到主体可以是任何可以与应用交互的“用户”；

      SecurityManager： Shiro的心脏；所有具体的交互都通过SecurityManager进行控制；它管理着所有Subject、且负责进行认证和授权、及会话、缓存的管理。

     Authenticator：认证器，负责主体认证的。

     Authrizer：授权器，或者访问控制器，用来决定主体是否有权限进行相应的操作；即控制着用户能访问应用中的哪些功能；

     Realm：可以有1个或多个Realm，可以认为是安全实体数据源，即用于获取安全实体的；可以是JDBC实现，也可以是LDAP实现，或者内存实现等等；由用户提供；注意：Shiro不知道你的用户/权限存储在哪及以何种格式存储；所以我们一般在应用中都需要实现自己的Realm；

      SessionManager：Shiro就抽象自己的Session来管理主体与应用之间交互的数据；这样的话，比如我们在Web环境用，刚开始是一台Web服务器；接着又上了台EJB服务器；这时想把两台服务器的会话数据放到一个地方，这个时候就可以实现自己的分布式会话（如把数据放到Memcached服务器）；

    SessionDAO：DAO大家都用过，数据访问对象，用于会话的CRUD，比如我们想把Session保存到数据库，那么可以实现自己的SessionDAO，通过如JDBC写到数据库；比如想把Session放到Memcached中，可以实现自己的Memcached SessionDAO；另外SessionDAO中可以使用Cache进行缓存，以提高性能；

    CacheManager：缓存控制器，来管理如用户、角色、权限等的缓存的；因为这些数据基本上很少去改变，放到缓存中后可以提高访问的性能

   Cryptography：密码模块，Shiro提高了一些常见的加密组件用于如密码加密/解密的。

6、身份验证

        身份验证，即在应用中证明他就是他本人。一般提供如他们的身份ID 一些标识信息来表明他就是他本人，如提供身份证，用户名/密码来证明。在 shiro 中，用户需要提供principals [ˈprɪnsəpəlz]-身份和credentials [krəˈdenʃlz]证明给shiro，从而应用能验证用户身份：

       principals：身份，即主体的标识属性，可以是用户名、邮箱等，唯一即可。一个主体可以有多个principals，但只有一个Primary principals，一般是用户名/密码/手机号。

       credentials：证明/凭证，即只有主体知道的安全值，如密码/数字证书等。最常见的principals和credentials组合就是用户名/密码。

DEMO：登录、退出                 官网：http://shiro.apache.org/

      1、首先准备一些用户身份/凭据（shiro.ini），ini配置文件通过[users]指定两个主体

[users]
    zhang=123
    wang=123

     2、测试用例org.apache.shiro.mgt.SecurityManager：SecurityManager

​

//1 init SecurityManager工厂
Factory<SecurityManager> factory = new IniSecurityManagerFactory("classpath:shiro.ini");
//2 获取SecurityManager工厂
SecurityManager securityManager = factory.getInstance();
//3 得到SecurityManager实例并绑定给SecurityUtils SecurityUtils.setSecurityManager(securityManager);
//4 得到Subject及创建用户名/密码身份验证Token（即用户身份/凭证）
Subject subject = SecurityUtils.getSubject();
UsernamePasswordToken token = new UsernamePasswordToken("zhang", "123");
try {subject.login(token); //5 登录，即身份验证} catch (AuthenticationException e) {}
Assert.assertEquals(true, subject.isAuthenticated()); //断言用户已经登录
subject.logout();//6、退出

[点击并拖拽以移动]
​

6.1 身份认证流程

1、首先调用Subject.login(token)进行登录，其会自动委托给Security Manager，调用之前必

须通过SecurityUtils. setSecurityManager()设置；

2、SecurityManager负责真正的身份验证逻辑；它会委托给Authenticator进行身份验证；

3、Authenticator才是真正的身份验证者，Shiro API中核心的身份认证入口点，此处可以自

定义插入自己的实现；

4、Authenticator可能会委托给相应的AuthenticationStrategy进行多Realm身份验证，默认

ModularRealmAuthenticator会调用AuthenticationStrategy进行多Realm身份验证；

5、Authenticator 会把相应的token 传入Realm，从Realm 获取身份验证信息，如果没有返

回/抛出异常表示身份验证失败了。此处可以配置多个Realm，将按照相应的顺序及策略进

行访问。

6.1.1、Realm

域，Shiro 从Realm获取安全数据（如用户、角色、权限），就是说SecurityManager

要验证用户身份，那它需要从Realm获取相应的用户进行比较以确定用户身份是否合法；

也需要从Realm得到用户相应的角色/权限进行验证用户是否能进行操作；可以把Realm看

成DataSource，即安全数据源。

可自定义单 Realm配置：

#声明一个realm
myRealm1=com.github.zhangkaitao.shiro.chapter2.realm.MyRealm1
#指定securityManager的realms实现
securityManager.realms=$myRealm1

自定义Realm实现：

public class MyRealm1 implements Realm {
@Override
public String getName() {
return "myrealm1";
}
@Override
public boolean supports(AuthenticationToken token) {
//仅支持UsernamePasswordToken 类型的Token
return token instanceof UsernamePasswordToken;
}
@Override
public AuthenticationInfo getAuthenticationInfo(AuthenticationToken token) throws
AuthenticationException {
String username = (String)token.getPrincipal(); //得到用户名
String password = new String((char[])token.getCredentials()); //得到密码
if(!"zhang".equals(username)) {
throw new UnknownAccountException(); //如果用户名错误
}
if(!"123".equals(password)) {
throw new IncorrectCredentialsException(); //如果密码错误
}
//如果身份认证验证成功，返回一个AuthenticationInfo实现；
return new SimpleAuthenticationInfo(username, password, getName());
}
}

7、授权

授权也叫访问控制，即在应用中控制谁能访问哪些资源（如访问页面/编辑数据/页面操作等）。在授权中需了解的几个关键对象：主体（Subject）、资源（Resource）、权限（Permission）、角色（Role）。

主体即访问应用的用户，在Shiro中使用Subject代表该用户。用户只有授权后才允许访

问相应的资源。

资源在应用中用户可以访问的任何东西，比如访问JSP 页面、查看/编辑某些数据、访问某个业务方法、打印文本等等都是资源。用户只要授权后才能访问。

权限安全策略中的原子授权单位，通过权限我们可以表示在应用中用户有没有操作某个资源的权力。即权限表示在应用中用户能不能访问某个资源，如：访问用户列表页面,

查看/新增/修改/删除用户数据（即很多时候都是CRUD（增查改删）式权限控制）,打印文档等等。

角色代表了操作集合，可以理解为权限的集合，一般情况下我们会赋予用户角色而不是权限，即这样用户可以拥有一组权限，赋予权限时比较方便。典型的如：项目经理、技术总监、CTO、开发工程师等都是角色，不同的角色拥有一组不同的权限。

7.1 授权方式

编程式：通过写if/else 授权代码块完成,Subject subject = SecurityUtils.getSubject();

if(subject.hasRole(“admin”)) {….}

注解式：通过在执行的Java方法上放置相应的注解完成@RequiresRoles("admin")

public void hello() {….}

JSP/GSP 标签：在JSP/GSP 页面通过相应的标签完成

<shiro:hasRole name="admin"><!— 有权限—></shiro:hasRole>

7.2 授权

1）基于角色的访问控制（隐式角色）

ini配置文件配置用户拥有的角色（shiro-role.ini）：

[users]
zhang=123,role1,role2
wang=123,role1

实现：

Subject subject = SecurityUtils.getSubject();
subject().hasAllRoles(Arrays.asList("role1", "role2")));

2）基于资源的访问控制（显示角色）

ini配置文件配置用户拥有的角色及角色-权限关系（shiro-permission.ini）：

[users]
zhang=123,role1,role2
wang=123,role1
[roles]
role1=user:create,user:update
role2=user:create,user:delete

      规则：“用户名=密码，角色1，角色2” “角色=权限1，权限2”，即首先根据用户名找到角色，然后根据角色再找到权限；即角色是权限集合；Shiro 不进行权限的维护，需要我们通过Realm返回相应的权限信息。

实现：

Subject subject = SecurityUtils.getSubject();
subject().isPermitted("user:create");
subject().isPermittedAll("user:update", "user:delete");

7.3 Permission

字符串通配符权限

      规则：“资源标识符：操作：对象实例ID” 即对哪个资源的哪个实例可以进行什么操作。其默认支持通配符权限字符串，“:”表示资源/操作/实例的分割；“,”表示操作的分割；“*”表示任意资源/操作/实例。

资源权限判断

     subject().checkPermissions("system:user:update", "system:user:delete");

权限字符串缺失部分的处理

     如“user:view”等价于“user:view:*”；而“organization”等价于“organization:*”或者“organization:*:*”。可以这么理解，这种方式实现了前缀匹配。另外如“user:*”可以匹配如“user:delete”、“user:delete”可以匹配如“user:delete:1”、“user:*:1”可以匹配如“user:view:1”、“user”可以匹配“user:view”或“user:view:1”等。即*可以匹配所有，不加*可以进行前缀匹配；但是如“*:view”不能匹配“system:user:view”，需要使用“*:*:view”，即后缀匹配必须指定前缀（多个冒号就需要多个*来匹配）。

性能问题

       通配符匹配方式比字符串相等匹配来说是更复杂的，因此需要花费更长时间，但是一般系统的权限不会太多，且可以配合缓存来提供其性能，如果这样性能还达不到要求我们可以实现位操作算法实现性能更好的权限匹配。另外实例级别的权限验证如果数据量太大也不建议使用，可能造成查询权限及匹配变慢。可以考虑比如在sql 查询时加上权限字符串之类的方式在查询时就完成了权限匹配。

7.4 授权流程

流程如下：

1、首先调用Subject.isPermitted*/hasRole*接口，其会委托给SecurityManager，而

SecurityManager接着会委托给Authorizer；

2、Authorizer是真正的授权者，如果我们调用如isPermitted(“user:view”)，其首先会通过

PermissionResolver把字符串转换成相应的Permission实例；

3、在进行授权之前，其会调用相应的Realm获取Subject相应的角色/权限用于匹配传入的

角色/权限；

4、Authorizer会判断Realm的角色/权限是否和传入的匹配，如果有多个Realm，会委托给

ModularRealmAuthorizer 进行循环判断，如果匹配如isPermitted*/hasRole*会返回true，否

则返回false表示授权失败。

ModularRealmAuthorizer进行多Realm匹配流程：

1、首先检查相应的Realm是否实现了实现了Authorizer；

2、如果实现了Authorizer，那么接着调用其相应的isPermitted*/hasRole*接口进行匹配；

3、如果有一个Realm匹配那么将返回true，否则返回false。

如果Realm进行授权的话，应该继承AuthorizingRealm，其流程是：

3.1.1、如果调用hasRole*，则直接获取AuthorizationInfo.getRoles()与传入的角色比较即可；

3.1.2、首先如果调用如isPermitted(“user:view”)，首先通过PermissionResolver 将权限字符串转换成相应的Permission 实例，默认使用WildcardPermissionResolver，即转换为通配符的WildcardPermission；

2 、通过AuthorizationInfo.getObjectPermissions() 得到Permission 实例集合；通过

AuthorizationInfo. getStringPermissions()得到字符串集合并通过PermissionResolver 解析为

Permission 实例；然后获取用户的角色，并通过RolePermissionResolver 解析角色对应的权

限集合（默认没有实现，可以自己提供）；

3、接着调用Permission. implies(Permission p)逐个与传入的权限比较，如果有匹配的则返回

true，否则false。

7.4.1、Realm

可自定义单 Realm配置：

#声明一个realm
myRealm1=com.github.zhangkaitao.shiro.chapter2.realm.MyRealm1
#指定securityManager的realms实现
securityManager.realms=$myRealm1

自定义Realm实现：

public class MyRealm1 implements Realm {
@Override
public String getName() {
return "myrealm1";
}
@Override
public boolean supports(AuthenticationToken token) {
//仅支持UsernamePasswordToken 类型的Token
return token instanceof UsernamePasswordToken;
}
@Override
protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) {
SimpleAuthorizationInfo authorizationInfo = new SimpleAuthorizationInfo();
authorizationInfo.addRole("role1");
authorizationInfo.addRole("role2");
authorizationInfo.addObjectPermission(new BitPermission("+user1+10"));
authorizationInfo.addObjectPermission(new WildcardPermission("user1:*")); 
}

@Override
public AuthenticationInfo getAuthenticationInfo(AuthenticationToken token) throws
AuthenticationException {
….代码见6.1.1，省略
}
}