springsecurity的工作原理

结构总览


Spring Security所解决的问题就是安全访问控制

安全访问控制功能其实就是对所有进入系统的请求进行拦截,校验每个请求是否能够访问它所期望的资源。

根据前边知识的学习,可以通过Filter或AOP等技术来实现,

Spring Security对Web资源的保护是靠Filter实现的,所以从这个Filter来入手,逐步深入Spring Security原理。
当初始化Spring Security时,会创建一个名为SpringSecurityFilterChainServlet过滤器

类型为org.springframework.security.web.FilterChainProxy,它实现了javax.servlet.Filter,

因此外部的请求会经过此类,下图是Spring Security过滤器链结构图:

springsecurity的工作原理_第1张图片

FilterChainProxy是一个代理

真正起作用的是FilterChainProxy中SecurityFilterChain所包含的各个Filter,

同时这些Filter作为Bean被Spring管理,它们是Spring Security核心,各有各的职责,

但他们并不直接处理用户的认证,也不直接处理用户的授权,

而是把它们交给了认证管理器(AuthenticationManager)决策管理器(AccessDecisionManager)进行处理,

下图是FilterChainProxy相关类的UML图示。

springsecurity的工作原理_第2张图片

spring Security功能的实现主要是由一系列过滤器链相互配合完成。

springsecurity的工作原理_第3张图片

下面介绍过滤器链中主要的几个过滤器及其作用:
SecurityContextPersistenceFilter 这个Filter是整个拦截过程的入口和出口(也就是第一个和最后一个拦截器),

                                                         会在请求开始时从配置好的 SecurityContextRepository 中获取 SecurityContext,

                                                         然后把它设置给SecurityContextHolder。

                                                         在请求完成后将 SecurityContextHolder 持有的 SecurityContext 再保存到配置好的 SecurityContextRepository,

                                                         同时清除 securityContextHolder 所持有的 SecurityContext;
UsernamePasswordAuthenticationFilter 用于处理来自表单提交的认证。该表单必须提供对应的用户名和密码,

                                                                    其内部还有登录成功或失败后进行处理的 AuthenticationSuccessHandler 和 AuthenticationFailureHandler,这些都可以根据需求做相关改变;
FilterSecurityInterceptor  是用于保护web资源的,使用AccessDecisionManager对当前用户进行授权访问
ExceptionTranslationFilter   能够捕获来自 FilterChain 所有的异常,并进行处理。但是它只会处理两类异常:
                                                AuthenticationException AccessDeniedException,其它的异常它会继续抛出。



认证流程

springsecurity的工作原理_第4张图片

springsecurity的工作原理_第5张图片

springsecurity的工作原理_第6张图片



AuthenticationProvider

通过前面的Spring Security认证流程得知,认证管理器(AuthenticationManager)委托AuthenticationProvider完成认证工作。
AuthenticationProvider是一个接口,定义如下:

public interface AuthenticationProvider {
    Authentication authenticate(Authentication authentication) throws AuthenticationException;
    boolean supports(Class var1);
}

springsecurity的工作原理_第7张图片

DaoAuthenticationProvider的基类     AbstractUserDetailsAuthenticationProvider发现以下代码:

public boolean supports(Class authentication) {
    return UsernamePasswordAuthenticationToken.class.isAssignableFrom(authentication);
}

也就是说当web表单提交用户名密码时,Spring Security由DaoAuthenticationProvider处理。



最后,我们来看一下Authentication(认证信息)的结构,

它是一个接口,我们之前提到的UsernamePasswordAuthenticationToken就是它的实现之一:

springsecurity的工作原理_第8张图片

(1)Authentication是spring security包中的接口,直接继承自Principal类,而Principal是位于java.security包中的。它是表示着一个抽象主体身份,任何主体都有一个名称,因此包含一个getName()方法。
(2)getAuthorities(),权限信息列表,默认是GrantedAuthority接口的一些实现类,通常是代表权限信息的一系列字符串。
(3)getCredentials(),凭证信息,用户输入的密码字符串,在认证过后通常会被移除,用于保障安全。
(4)getDetails(),细节信息,web应用中的实现接口通常为 WebAuthenticationDetails,它记录了访问者的ip地址和sessionId的值。
(5)getPrincipal(),身份信息,大部分情况下返回的是UserDetails接口的实现类,UserDetails代表用户的详细信息,

           那从Authentication中取出来的UserDetails就是当前登录用户信息,它也是框架中的常用接口之一。



UserDetailsService

1)认识UserDetailsService
现在咱们现在知道DaoAuthenticationProvider处理了web表单的认证逻辑,认证成功后既得到一个Authentication(UsernamePasswordAuthenticationToken实现),里面包含了身份信息(Principal)。

这个身份信息就是一个Object ,大多数情况下它可以被强转为UserDetails对象。
DaoAuthenticationProvider中包含了一个UserDetailsService实例,它负责根据用户名提取用户信息UserDetails(包含密码),

而后DaoAuthenticationProvider会去对比UserDetailsService提取的用户密码与用户提交的密码是否匹配作为认证成功的关键依据,

因此可以通过将自定义的UserDetailsService 公开为spring bean来定义自定义身份验证。

public interface UserDetailsService {
     UserDetails loadUserByUsername(String username) throws UsernameNotFoundException;
}

很多人把DaoAuthenticationProviderUserDetailsService的职责搞混淆,其实UserDetailsService只负责从特定的地方(通常是数据库)加载用户信息,仅此而已。

而DaoAuthenticationProvider的职责更大,它完成完整的认证流程,同时会把UserDetails填充至Authentication。

上面一直提到UserDetails是用户信息,咱们看一下它的真面目:

springsecurity的工作原理_第9张图片

它和Authentication接口很类似,

比如它们都拥有username,authorities。Authentication的getCredentials()与UserDetails中的getPassword()需要被区分对待,

前者是用户提交的密码凭证,后者是用户实际存储的密码,认证
其实就是对这两者的比对。

Authentication中的getAuthorities()实际是由UserDetails的getAuthorities()传递而形成的。

还记得Authentication接口中的getDetails()方法吗?其中的UserDetails用户详细信息便是经过了AuthenticationProvider认证之后被填充的。
通过实现UserDetailsService和UserDetails,我们可以完成对用户信息获取方式以及用户信息字段的扩展。
Spring Security提供的InMemoryUserDetailsManager(内存认证),JdbcUserDetailsManager(jdbc认证)就是UserDetailsService的实现类,主要区别无非就是从内存还是从数据库加载用户。

你可能感兴趣的:(spring,security)