Spring Security是做安全访问控制,对所有进入系统的请求进行拦截,并做校验,这可以通过Filter或者AOP实现,Spring Security靠Filter。
Spring Security功能的实现就是一系列过滤器链相互配合。
SecurityContextPersistenceFilter 这个Filter是整个拦截过程的入口和出口,也就是第一个和最后一个拦截器。会在请求开始时从配置好的 SecurityContextRepository 中获取 SecurityContext,然后把它设置给 SecurityContextHolder。在请求完成后将 SecurityContextHolder 持有的 SecurityContext 再保存到配置好的 SecurityContextRepository,同时清除 securityContextHolder 所持有的 SecurityContext;
UsernamePasswordAuthenticationFilter 用于处理来自表单提交的认证,该表单必须提供对应的用户名和密码,其内部还有登录成功或失败后进行处理的 AuthenticationSuccessHandler 和 AuthenticationFailureHandler,这些都可以根据需求做相关改变;(这些处理器的逻辑可自定义,重新实现一下这个处理器)
ExceptionTranslationFilter 能够捕获来自 FilterChain 所有的异常,并进行处理。但是它只会处理两类异常:AuthenticationException 和 AccessDeniedException,其它的异常它会继续抛出。
FilterSecurityInterceptor 是用于保护web资源的,使用AccessDecisionManager对当前用户进行授权访问
SpringSecurity的执行流程:
总之,整个框架中,AuthenticationProvider(DaoAuthenticationProvider)承上启下,而通过实现UserDetailsService和UserDetails,可以完成对用户信息获取方式以及用户信息字段的扩展。
认证管理器AuthenticationManager委托AuthenticationProvider完成认证工作,AuthenticationProvider接口定义如下:
public interface AuthenticationProvider { Authentication authenticate(Authentication authentication) throws AuthenticationException; //supports方法来表明自己支持的认证方式 boolean supports(Class> var1); }
authenticate()方法定义了认证的实现过程。传参为Authentication,里面包含登录用户所提交的用户名密码等。返回也是Authentication对象,且是一个认证通过后,被填充权限等信息的Authentication。
supports方法来表明自己支持的认证方式。如使用表单方式认证,在提交请求时Spring Security会生成UsernamePasswordAuthenticationToken(Authentication的子类),里面封装着用户提交的用户名、密码信息。
//当web表单提交用户名密码时,Spring Security由DaoAuthenticationProvider处理 //其supports方法中就是UsernamePasswordAuthenticationToken.class public boolean supports(Class> authentication) { return UsernamePasswordAuthenticationToken.class.isAssignableFrom(authentication); }
Authentication继承自Principal,Principal是框架用来表示一个抽象主体的类(如人、用户、公司),任何主体都有名称,因此其有个getName方法
Authentication源码如下:
public interface Authentication extends Principal, Serializable { //获取权限信息列表,默认是GrantedAuthority接口的一些实现类 Collection extends GrantedAuthority> getAuthorities(); //获取凭证信息,用户输入的密码字符串,在认证过后通常会被移除,用于保障安全 Object getCredentials(); //细节信息,web应用中的实现接口通常为 WebAuthenticationDetails,它记录了访问者的ip地址和sessionId的值 Object getDetails(); //身份信息,大部分情况下返回的是UserDetails接口的实现类,UserDetails代表用户的详细信息,那从Authentication中取出来的UserDetails就是当前登录用户信息,它也是框架中的常用接口之一 Object getPrincipal(); boolean isAuthenticated(); void setAuthenticated(boolean var1) throws IllegalArgumentException; }
public interface UserDetails extends Serializable { Collection extends GrantedAuthority> getAuthorities(); String getPassword(); String getUsername(); boolean isAccountNonExpired(); boolean isAccountNonLocked(); boolean isCredentialsNonExpired(); boolean isEnabled(); }
UserDetails和Authentication相似看着。而实际前者是库里存的信息,后者是用户提交的信息。
Authentication的getCredentials()与UserDetails中的getPassword()需要被区分对待,前者是用户提交的密码凭证,后者是用户实际存储的密码,认证其实就是对这两者的比对。
再看这个流程图,即AuthenticationProvider通过loadUserByUsername拿到的UserDetails,如果和表单提交封装的Authentication里的密码相等,则填充权限信息到Authentication。而Authentication中的权限信息,实际就是由UserDetails的getAuthorities()传递而形成的。
public interface UserDetailsService { UserDetails loadUserByUsername(String username) throws UsernameNotFoundException; }
DaoAuthenticationProvider聚合UserDetailsService对象,this.userDetailsService.loadUserByUsername去根据用户名获取到库里的用户信息(包括密码、权限)。然后DaoAuthenticationProvider对比表单提交后封装的Authentication对象里的用户信息是否等于loadUserByUsername到的UserDetails的用户信息。
UserDetailsService只负责从特定的地方(通常是数据库)加载用户信息,仅此而已。DaoAuthenticationProvider的职责更大,它完成完整的认证流程,同时会把UserDetails信息填充至Authentication。(然后一开始的过滤器把填充后的Authentication给set到了SecurityContextHolder,因此才有了后面从SecurityContextHolder获取当前登录用户)
Spring Security提供的InMemoryUserDetailsManager(内存认证),JdbcUserDetailsManager(jdbc认证),就是
UserDetailsService的实现类,区别就是从内存还是从数据库加载用户。
已认证的用户访问受保护的web资源:
而决策接口为:
public interface AccessDecisionManager { /** * 通过传递的参数来决定用户是否有访问对应受保护资源的权限 * authentication:要访问资源的访问者的身份 * object:要访问的受保护资源,web请求对应FilterInvocation * configAttributes:是受保护资源的访问策略,通过SecurityMetadataSource获取。 */ void decide(Authentication authentication , Object object, CollectionconfigAttributes ) throws AccessDeniedException, InsufficientAuthenticationException; //略.. }
AccessDecisionManager的实现类中聚合了投票者接口AccessDecisionVoter的一系列子实现类。通过vote方法的返回结果分析投票结果:
public interface AccessDecisionVoter{ //同意访问 int ACCESS_GRANTED = 1; //弃权 int ACCESS_ABSTAIN = 0; //拒绝访问 int ACCESS_DENIED = ‐1; boolean supports(ConfigAttribute var1); boolean supports(Class> var1); int vote(Authentication var1, S var2, Collectionvar3); }
对AccessDecisionVoter不同的投票结果,AccessDecisionManager的三个实现类,分析的结果也不同。如ConsensusBased的逻辑是赞成票多于反对票则表示通过。
看完上面的UserDetails对象和UserDetailsService接口的loadUserByUsername方法后,再看之前在内存中定义用户,是这样的:
UserDetails user2 = User.builder() .username("liu") .password(passwordEncoder().encode("123456")) .authorities("teacher:add","teacher:update") .roles("teacher") .build();
查看User类的源码,其实现了UserDetails接口,因此上面才可以直接创建User对象。
接下来自己定义一个用户类SecurityUser类,也去实现UserDetails接口,重写UserDetails接口方法时,直接写死一个用户信息,一会儿new这个自定义的SecurityUser类,也就和上面的User.builder一个意思。
public class SecurityUser implements UserDetails { @Override public Collection extends GrantedAuthority> getAuthorities() { return null; //未给权限 } @Override public String getPassword() { //明文为123456 //return "$2a$10$KyXAnVcsrLaHMWpd3e2xhe6JmzBi.3AgMhteFq8t8kjxmwL8olEDq"; return new BCryptPasswordEncoder().encode("123456"); } @Override public String getUsername() { return "liu"; } @Override public boolean isAccountNonExpired() { return true; } @Override public boolean isAccountNonLocked() { return true; } @Override public boolean isCredentialsNonExpired() { return true; } @Override public boolean isEnabled() { return true; } }
UserDetails 接口的7个方法如下图:
方法名 | 作用 |
---|---|
getAuthorities() | 获取当前用户对象所具有的角色信息 |
getPassword() | 获取当前用户对象的密码 |
getUsername() | 获取当前用户对象的用户名 |
isAccountNonExpired() | 当前账户是否未过期 |
isAccountNonLocked() | 当前账户是否未锁定 |
isCredentialsNonExpired() | 当前账户密码是否未过期 |
isEnabled() | 当前账户是否可用 |
UserDetails的用户对象建好了,继续看之前在内存中创建用户的实现思路:
InMemoryUserDetailsManager userDetailsManager = new InMemoryUserDetailsManager(); userDetailsManager.createUser(user1); userDetailsManager.createUser(user2);
InMemoryUserDetailsManager类实现了UserDetailsManager接口,UserDetailsManager接口又继承了UserDetailService接口:
自己新建一个类UserServiceImpl去实现UserDetailService接口。重写loadUserByUsernam方法,并当用户名等于自定义的SecurityUser对象中的用户名时,返回SecurityUser对象。
@Service public class UserServiceImpl implements UserDetailsService { @Override public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException { SecurityUser securityUser= new SecurityUser(); if(username==null || !username.equals(securityUser.getUsername())){ throw new UsernameNotFoundException("该用户不存在"); } return securityUser; } }
以上其实是自己玩了下5.6两步:
重启服务,登录下,一切正常。
上面自定义的SecurityUser类中,关于权限的方法返回null,写个接口返回认证信息,可以看到权限字段确实为null:
加权:
@Override public Collection extends GrantedAuthority> getAuthorities() { GrantedAuthority g1=()->"student:query"; //使用lambda表达式 //GrantedAuthority g1=new SimpleGrantedAuthority("student:query"); ListgrantedAuthorityList=new ArrayList<>(); grantedAuthorityList.add(g1); return grantedAuthorityList; }
顺便使用@PreAuthorize注解方便后面看下效果:
@RestController @RequestMapping("/student") public class StudentController { @GetMapping("/query") @PreAuthorize("hasAuthority('student:query')") public String queryInfo(HttpServletRequest request){ return "I am a student,My name is XXX"; } }
重启后查看认证信息:
梳理完UserDetails和UserDetailsService接口之间的流程和细节,方便后面理解SpringSecurity基于数据库认证。