Springboot之安全管理（一）

安全框架的介绍

在 Web 开发中，安全一直是非常重要的一个方面。安全虽然属于应用的非功能性需求，但是应该在应用开发的初期就考虑进来。 如果在应用开发的后期才考虑安全的问题，就可能陷入一个两难的境地：一方面，应用存在严重的安全漏洞，无法满足用户的要求，并可能造成用户的隐私数据被攻击者窃取；另一方面，应用的基本架构已经确定，要修复安全漏洞，可能需要对系统的架构做出比较重大的调整，因而需要更多的开发时间，影响应用的发布进程。因此，从应用开发的第一天就应该把安全相关的因素考虑进来，并在整个应用的开发过程中。 而安全框架可以帮我们方便、更好的实现安全和权限控制。

Spring Boot应用常用的安全框架有Spring Security 和 Shiro。Spring 官方提供了spring-boot-starter-security，用Spring Initializr可以非常方便用上Spring Security。就像Mybatis的Starter一样，Shiro的Spring Boot Starter是第三方开源社区提供的，自己也可以添加。下面会分别介绍shiro和Spring Security的使用。

shiro

介绍

shiro是一个Java的安全框架，相对于 Spring Security，shiro更加轻量并且简单。

​ shiro不仅可以用于JavaEE，也可以用于JavaSe，主要可以帮我们提供一下功能：认证、授权、加密、会话管理、缓存等

shiro内部架构如下：

外部都通过Subject来与应用进行交互，再由Security Manager做处理分发到各个相应的模块(类似于springMVC的dispatchServlet)，处理模块在通过Realm获取所需要的数据，做校验或者CRUD。

shiro特点

• 易于使用——易用性是项目的最终目标。应用程序安全非常令人困惑和沮丧,被认为是“不可避免的灾难”。如果你让它简化到新手都可以使用它,它就将不再是一种痛苦了。
• 全面——没有其他安全框架的宽度范围可以同Apache Shiro一样,它可以成为你的“一站式”为您的安全需求提供保障。
• 灵活——Apache Shiro可以在任何应用程序环境中工作。虽然在网络工作、EJB和IoC环境中可能并不需要它。但Shiro的授权也没有任何规范,甚至没有许多依赖关系。
• Web支持——Apache Shiro拥有令人兴奋的web应用程序支持,允许您基于应用程序的url创建灵活的安全策略和网络协议(例如REST),同时还提供一组JSP库控制页面输出。
• 低耦合——Shiro干净的API和设计模式使它容易与许多其他框架和应用程序集成。你会看到Shiro无缝地集成Spring这样的框架, 以及Grails, Wicket, Tapestry, Mule, Apache Camel, Vaadin…等。
• 被广泛支持——Apache Shiro是Apache软件基金会的一部分。项目开发和用户组都有友好的网民愿意帮助。这样的商业公司如果需要Katasoft还提供专业的支持和服务。

功能

1. Authentication：身份认证/登录，验证用户是不是拥有相应的身份；
2. Authorization：授权，即权限验证，验证某个已认证的用户是否拥有某个权限；即判断用户是否能做事情，常见的如：验证某个用户是否拥有某个角色。或者细粒度的验证某个用户对某个资源是否具有某个权限；
3. Session Manager：会话管理，即用户登录后就是一次会话，在没有退出之前，它的所有信息都在会话中；会话可以是普通JavaSE环境的，也可以是如Web环境的；
4. Cryptography：加密，保护数据的安全性，如密码加密存储到数据库，而不是明文存储；
5. Web Support：Web支持，可以非常容易的集成到Web环境；
6. Caching：缓存，比如用户登录后，其用户信息、拥有的角色/权限不必每次去查，这样可以提高效率；
7. Concurrency：shiro支持多线程应用的并发验证，即如在一个线程中开启另一个线程，能把权限自动传播过去；
8. Testing：提供测试支持；
9. Run As：允许一个用户假装为另一个用户（如果他们允许）的身份进行访问；
10. Remember Me：记住我，这个是非常常见的功能，即一次登录后，下次再来的话不用登录了。

原理分析

**shiro的核心是javaservlet规范中的filter，通过配置拦截器，使用拦截器链来拦截请求，**如果允许访问，则通过。通常情况下，系统的登录、退出会配置拦截器。登录的时候，调用subject.login(token),token是用户验证信息，这个时候会在Realm中doGetAuthenticationInfo方法中进行认证。这个时候会把用户提交的验证信息与数据库中存储的认证信息进行比较，一致则允许访问，并在浏览器种下此次回话的cookie，在服务器端存储session信息。退出的时候，调用subject.logout()，会清除回话信息。

核心组件

Subject

主体，与应用交互的“用户”，个人觉得可以理解为暴露在外的客户端(Client)，由此来访问应用，基本上所有身份验证、授权都是通过Subject完成。默认实现类为 DelegatingSubject。

一般通过 subject.login() 来做用户登录，subject.hasRole*/isPermitted* 查询是否存在角色/权限

 // Subject由SecurityManager管理，因此需要先绑定
 SecurityUtils.setSecurityManager(securityManager);
    // 获取subject
  Subject subject = SecurityUtils.getSubject();

SecurityManager

Shiro真正的入口，控制所有与交互，并且管理所有Subject，是Shiro的核心。

Authenticator

​ 认证器，用来管登录的，经常会跟下面的Authrizer搞混用途。可以根据 ca 还是za 来作区分。

认证器主要识别判断用户能不能进去应用，相当于看你对于应用是不是合法的。shiro提供了一个默认的验证方式(ModularRealmAuthenticator),如果需要自己自定义验证策略，可以实现自己的一个 AuthenticationStragy,并制定给ModularRealmAuthenticator，ModularRealmAuthenticator会再验证的时候调用。 默认策略是 AtLeastOneSuccessfulStrategy，功能如下：

shiro框架中提供的AntuenticationStrategy实现：

• FirstSuccessfulStrategy：只要有一个Realm验证成功即可，只返回第一个Realm身份验证成功的验证信息，其他忽略；
• AtleastOneSuccessfulStrategy：只要有一个Realm验证成功即可，返回所有的Realm身份验证成功的信息，也就是说每个Realm都会验证
• allSuccessfulStrategy：所有Realm验证成功才算成功，返回所有Realm身份验证成功的信息

自定义实现时一般继承 org.apache.shiro.authc.pam.AbstractAuthenticationStrategy 即可

Authrizer

授权器，用来管权限的。有两种权限概念，隐式角色(RBAC，基于角色)以及显示角色(RBAC新解、基于权限),两者区别在于粒度的不同， 显示角色更加细

RBAC所代表的是对角色进行控制，即只控制资源与角色之间的关系，并且一般来说这里的资源粒度只是细化到页面，但是对于一些要求更加细致的权限控制（控制到按钮）单纯的架构层面就无法满足，此时就需要程序员对页面进行处理，架构层面的需要后期处理就说明设计模式有所欠缺。
RBAC新解所代表的是粒度比RBAC对资源划分更加细化，它直接对访问资源的任何操作做权限控制

授权器流程

1. subject调用 isPermitted* 或者 hasRole 接口，委托给 SecurityManager， SecurityManager委托给对应的 Authorizer; （类似登录）
2. Authorizer是真正的授权者，根据调用方法验证授权
   在进行授权之前，会调用相应的Realm获取Subject相应的角色/权限用于匹配传入的角色/权限
3. Authorizer 会判断Realm的角色/权限是否和传入的匹配，如果有多个Realm，会委托给
4. ModularRealmAuthorizer 进行循环判断，匹配返回 true，不匹配返回 false

在授权过程中，还需要两个解析器：PermissionResolver 和 RolePermissionResolver

PermissionResolver - 权限解析器，在authorizer中设置，自定义实现可以实现PermissionResolver，默认实现为 WildcardPermissionResolver

​ RolePermissionResolver - 角色解析器，在authorizer中设置,自定义实现可以实现RolePermissionResolver，shiro没有提供 默认实现

Realm

Realm，可以理解为Shiro的数据源，主要用于存放用户、角色、权限等信息，三者之间的关系为：用户-角色之间多对多，角色-权限之间多对多

Realm可以是jdbc实现，也可以是LDAP实现或者内存实现，写死配置都可以，由用户自己提供，一般也是自己来实现需要的Realm。下面展示shiro提供的realm关系。

由Realm的继承关系可以看出，Shiro的不同功能划分是通过java的继承关系来完成的(好像又有点像废话)。AuthenticatingRealm 类有缓存以及认证功能，AuthorizingRealm 类继承 AuthenticationgRealm ，拓展了授权功能，之后，再根据实际业务做区分，连数据库的jdbcRealm，读取配置的IniRealm等等

Spring security

介绍

Spring Security是一个能够为基于Spring的企业应用系统提供声明式的安全访问控制解决方案的安全框架。它提供了一组可以在Spring应用上下文中配置的Bean，充分利用了Spring IoC，DI（控制反转Inversion of Control ,DI:Dependency Injection 依赖注入）和AOP（面向切面编程）功能，为应用系统提供声明式的安全访问控制功能，减少了为企业系统安全控制编写大量重复代码的工作。

功能

Spring Security对Web安全性的支持大量地依赖于Servlet过滤器。这些过滤器拦截进入请求，并且在应用程序处理该请求之前进行某些安全处理。 Spring Security提供有若干个过滤器，它们能够拦截Servlet请求，并将这些请求转给认证和访问决策管理器处理，从而增强安全性。根据自己的需要，可以使用适当的过滤器来保护自己的应用程序。

如果使用过Servlet过滤器且令其正常工作，就必须在Web应用程序的web.xml文件中使用<filter> 和<filter-mapping>元素配置它们。虽然这样做能起作用，但是它并不适用于使用依赖注入进行的配置。

FilterToBeanProxy是一个特殊的Servlet过滤器，它本身做的工作并不多，而是将自己的工作委托给Spring应用程序上下文 中的一个Bean来完成。被委托的Bean几乎和其他的Servlet过滤器一样，实现javax.servlet.Filter接 口，但它是在Spring配置文件而不是web.xml文件中配置的。

实际上，FilterToBeanProxy代理给的那个Bean可以是javax.servlet.Filter的任意实现。这可以是 Spring Security的任何一个过滤器，或者它可以是自己创建的一个过滤器。但是正如本书已经提到的那样，Spring Security要求至少配置四个而且可能一打或者更多的过滤器。

Security 原理分析

SpringSecurity 过滤器链

SpringSecurity 采用的是责任链的设计模式，它有一条很长的过滤器链。现在对这条过滤器链的各个进行说明:

1. WebAsyncManagerIntegrationFilter: 将Security上下文与Spring Web 中用于处理异步请求映射的WebAsyncManager进行集成。
2. SecurityContextPersistenceFilter：在每次请求处理之前将该请求相关的安全上下文信息加载到 SecurityContextHolder 中，然后在该次请求处理完成之后，将 SecurityContextHolder 中关于这次请求的信息存储到一个“仓储”中，然后将 SecurityContextHolder 中的信息清除，例如在Session中维护一个用户的安全信息就是这个过滤器处理的。
3. HeaderWriterFilter：用于将头信息加入响应中。
4. CsrfFilter：用于处理跨站请求伪造。
5. LogoutFilter：用于处理退出登录。
6. UsernamePasswordAuthenticationFilter：用于处理基于表单的登录请求，从表单中获取用户名和密码。默认情况下处理来自 /login 的请求。从表单中获取用户名和密码时，默认使用的表单 name 值为 username 和 password，这两个值可以通过设置这个过滤器的usernameParameter 和 passwordParameter 两个参数的值进行修改。
7. DefaultLoginPageGeneratingFilter：如果没有配置登录页面，那系统初始化时就会配置这个过滤器，并且用于在需要进行登录时生成一个登录表单页面。
8. BasicAuthenticationFilter：检测和处理 http basic 认证。
9. RequestCacheAwareFilter：用来处理请求的缓存。
10. SecurityContextHolderAwareRequestFilter：主要是包装请求对象request。
11. AnonymousAuthenticationFilter：检测 SecurityContextHolder 中是否存在 Authentication 对象，如果不存在为其提供一个匿名 Authentication。
12. SessionManagementFilter：管理 session 的过滤器
13. ExceptionTranslationFilter：处理 AccessDeniedException 和 AuthenticationException 异常。
14. FilterSecurityInterceptor：可以看做过滤器链的出口。
15. RememberMeAuthenticationFilter：当用户没有登录而直接访问资源时, 从 cookie 里找出用户的信息, 如果 Spring Security 能够识别出用户提供的remember me cookie, 用户将不必填写用户名和密码, 而是直接登录进入系统，该过滤器默认不开启。

工作流程说明

1. 客户端发起一个请求，进入 Security 过滤器链。
2. 当到 LogoutFilter 的时候判断是否是登出路径，如果是登出路径则到 logoutHandler ，如果登出成功则到 logoutSuccessHandler 登出成功处理，如果登出失败则由 ExceptionTranslationFilter ；如果不是登出路径则直接进入下一个过滤器。
3. 当到 UsernamePasswordAuthenticationFilter 的时候判断是否为登录路径，如果是，则进入该过滤器进行登录操作，如果登录失败则到 AuthenticationFailureHandler 登录失败处理器处理，如果登录成功则到 AuthenticationSuccessHandler 登录成功处理器处理，如果不是登录请求则不进入该过滤器。
4. 当到 FilterSecurityInterceptor 的时候会拿到 uri ，根据 uri 去找对应的鉴权管理器，鉴权管理器做鉴权工作，鉴权成功则到 Controller 层否则到 AccessDeniedHandler 鉴权失败处理器处理。

SpringSecurity 核心组件

1. SecurityContextHolder：提供对SecurityContext的访问
2. SecurityContext,：持有Authentication对象和其他可能需要的信息
3. AuthenticationManager：其中可以包含多个AuthenticationProvider
4. ProviderManager：对象为AuthenticationManager接口的实现类
5. AuthenticationProvider ：主要用来进行认证操作的类 调用其中的authenticate()方法去进行认证操作
6. Authentication：Spring Security方式的认证主体
7. GrantedAuthority：对认证主题的应用层面的授权，含当前用户的权限信息，通常使用角色表示
8. UserDetails：构建Authentication对象必须的信息，可以自定义，可能需要访问DB得到
9. UserDetailsService：通过username构建UserDetails对象，通过loadUserByUsername根据userName获取UserDetail对象 （可以在这里基于自身业务进行自定义的实现 如通过数据库，xml,缓存获取等）
   
   总结：简单来说，UserDetailService只单纯地负责存取用户信息，除了给框架内的其他组件提供数据外没有其他功能。而认证过程是由AuthenticationManager来完成的。