一直以来都想好好写一写spring security 系列文章，每每提笔又不知何处下笔，又赖于spring security体系强大又过于繁杂，且spring security 与auth2.0结合的时候又很难理解，最近项目告一段落，闲来无事好好对spring security 进行总结和回顾。
核心组件
主要介绍一些在Spring Security中常见且核心的Java类，这些类之间的关系构建起了整个spring security框架，因此首先来熟知这些类是非常有必要的。
SecurityContextHolder
SecurityContextHolder它持有的是安全上下文（security context）的信息。当前操作的用户是谁，该用户是否已经被认证，他拥有哪些角色权等等，这些都被保存在SecurityContextHolder中。SecurityContextHolder默认使用ThreadLocal 策略来存储认证信息。看到ThreadLocal 也就意味着，这是一种与线程绑定的策略。在web环境下，Spring Security在用户登录时自动绑定认证信息到当前线程，在用户退出时，自动清除当前线程的认证信息。
获取当前用户的信息
Object principal =SecurityContextHolder.getContext().getAuthentication().getPrincipal(); if (principal instanceof UserDetails) { String username = ((UserDetails)principal).getUsername(); } else { String username = principal.toString(); } getAuthentication()返回了认证信息，getPrincipal()返回了身份信息，UserDetails便是Spring对身份信息封装的一个接口。
SecurityContext
安全上下文，主要持有Authentication对象，如果用户未鉴权，那Authentication对象将会是空的。
public interface SecurityContext extends Serializable { // ~ Methods // ======================================================================================================== /** * Obtains the currently authenticated principal, or an authentication request token. * * @return the Authentication or null if no authentication * information is available */ Authentication getAuthentication(); /** * Changes the currently authenticated principal, or removes the authentication * information. * * @param authentication the new Authentication token, or * null if no further authentication information should be stored */ void setAuthentication(Authentication authentication);} Authentication
鉴权对象，该对象主要包含了用户的详细信息（UserDetails）和用户鉴权时所需要的信息，如用户提交的用户名密码、Remember-me Token，或者digest hash值等，按不同鉴权方式使用不同的Authentication实现。
public interface Authentication extends Principal, Serializable { // ~ Methods // ======================================================================================================== /** * Set by an AuthenticationManager to indicate the authorities that the * principal has been granted. Note that classes should not rely on this value as * being valid unless it has been set by a trusted AuthenticationManager. * * Implementations should ensure that modifications to the returned collection array * do not affect the state of the Authentication object, or use an unmodifiable * instance. *
* * @return the authorities granted to the principal, or an empty collection if the * token has not been authenticated. Never null. */ Collection getAuthorities(); /** * The credentials that prove the principal is correct. This is usually a password, * but could be anything relevant to the AuthenticationManager. Callers * are expected to populate the credentials. * * @return the credentials that prove the identity of the Principal */ Object getCredentials(); /** * Stores additional details about the authentication request. These might be an IP * address, certificate serial number etc. * * @return additional details about the authentication request, or null * if not used */ Object getDetails(); /** * The identity of the principal being authenticated. In the case of an authentication * request with username and password, this would be the username. Callers are * expected to populate the principal for an authentication request. * * The AuthenticationManager implementation will often return an * Authentication containing richer information as the principal for use by * the application. Many of the authentication providers will create a * {@code UserDetails} object as the principal. * * @return the Principal being authenticated or the authenticated * principal after authentication. */ Object getPrincipal(); /** * Used to indicate to {@code AbstractSecurityInterceptor} whether it should present * the authentication token to the AuthenticationManager. Typically an * AuthenticationManager (or, more often, one of its * AuthenticationProviders) will return an immutable authentication token * after successful authentication, in which case that token can safely return * true to this method. Returning true will improve * performance, as calling the AuthenticationManager for every request * will no longer be necessary. *
* For security reasons, implementations of this interface should be very careful * about returning true from this method unless they are either * immutable, or have some way of ensuring the properties have not been changed since * original creation. * * @return true if the token has been authenticated and the * AbstractSecurityInterceptor does not need to present the token to the * AuthenticationManager again for re-authentication. */ boolean isAuthenticated(); /** * See {@link #isAuthenticated()} for a full description. *
* Implementations should always allow this method to be called with a * false parameter, as this is used by various classes to specify the * authentication token should not be trusted. If an implementation wishes to reject * an invocation with a true parameter (which would indicate the * authentication token is trusted - a potential security risk) the implementation * should throw an {@link IllegalArgumentException}. * * @param isAuthenticated true if the token should be trusted (which may * result in an exception) or false if the token should not be trusted * * @throws IllegalArgumentException if an attempt to make the authentication token * trusted (by passing true as the argument) is rejected due to the * implementation being immutable or implementing its own alternative approach to * {@link #isAuthenticated()} */ void setAuthenticated(boolean isAuthenticated) throws IllegalArgumentException;}
1、 Authentication是spring security包中的接口，直接继承自Principal类，而Principal是位于java.security包中的。可以见得，Authentication在spring security中是最高级别的身份/认证的抽象。
2、 由这个顶级接口，我们可以得到用户拥有的权限信息列表，密码，用户细节信息，用户身份信息，认证信息。3、getAuthorities()，权限信息列表，默认是GrantedAuthority接口的一些实现类，通常是代表权限信息的一系列字符串。4、getCredentials()，密码信息，用户输入的密码字符串，在认证过后通常会被移除，用于保障安全。5、getDetails()，细节信息，web应用中的实现接口通常为 WebAuthenticationDetails，它记录了访问者的ip地址和sessionId的值。6、getPrincipal()，敲黑板！！！最重要的身份信息，大部分情况下返回的是UserDetails接口的实现类，也是框架中的常用接口之一。GrantedAuthority
该接口表示了当前用户所拥有的权限（或者角色）信息。这些信息由授权负责对象AccessDecisionManager来使用，并决定最终用户是否可以访问某资源（URL或方法调用或域对象）。鉴权时并不会使用到该对象。
UserDetails
这个接口规范了用户详细信息所拥有的字段，譬如用户名、密码、账号是否过期、是否锁定等。在Spring Security中，获取当前登录的用户的信息,一般情况是需要在这个接口上面进行扩展，用来对接自己系统的用户
public interface UserDetails extends Serializable { // ~ Methods // ======================================================================================================== /** * Returns the authorities granted to the user. Cannot return null. * * @return the authorities, sorted by natural key (never null) */ Collection getAuthorities(); /** * Returns the password used to authenticate the user. * * @return the password */ String getPassword(); /** * Returns the username used to authenticate the user. Cannot return null * . * * @return the username (never null) */ String getUsername(); /** * Indicates whether the user's account has expired. An expired account cannot be * authenticated. * * @return true if the user's account is valid (ie non-expired), * false if no longer valid (ie expired) */ boolean isAccountNonExpired(); /** * Indicates whether the user is locked or unlocked. A locked user cannot be * authenticated. * * @return true if the user is not locked, false otherwise */ boolean isAccountNonLocked(); /** * Indicates whether the user's credentials (password) has expired. Expired * credentials prevent authentication. * * @return true if the user's credentials are valid (ie non-expired), * false if no longer valid (ie expired) */ boolean isCredentialsNonExpired(); /** * Indicates whether the user is enabled or disabled. A disabled user cannot be * authenticated. * * @return true if the user is enabled, false otherwise */ boolean isEnabled();} UserDetailsService
这个接口只提供一个接口loadUserByUsername(String username)，这个接口非常重要，一般情况我们都是通过扩展这个接口来显示获取我们的用户信息，用户登陆时传递的用户名和密码也是通过这里这查找出来的用户名和密码进行校验，但是真正的校验不在这里，而是由AuthenticationManager以及AuthenticationProvider负责的，需要强调的是，如果用户不存在，不应返回NULL，而要抛出异常UsernameNotFoundException
public interface UserDetailsService { // ~ Methods // ======================================================================================================== /** * Locates the user based on the username. In the actual implementation, the search * may possibly be case sensitive, or case insensitive depending on how the * implementation instance is configured. In this case, the UserDetails * object that comes back may have a username that is of a different case than what * was actually requested.. * * @param username the username identifying the user whose data is required. * * @return a fully populated user record (never null) * * @throws UsernameNotFoundException if the user could not be found or the user has no * GrantedAuthority */ UserDetails loadUserByUsername(String username) throws UsernameNotFoundException;} Spring Security是如何完成身份认证的？
1、用户名和密码被过滤器获取到，封装成Authentication,通常情况下是UsernamePasswordAuthenticationToken这个实现类。
2、AuthenticationManager 身份管理器负责验证这个Authentication
3、认证成功后，AuthenticationManager身份管理器返回一个被填充满了信息的（包括上面提到的权限信息，身份信息，细节信息，但密码通常会被移除）Authentication实例。
4、SecurityContextHolder安全上下文容器将第3步填充了信息的Authentication，通过SecurityContextHolder.getContext().setAuthentication()方法，设置到其中。
AuthenticationManager
初次接触Spring Security的朋友相信会被AuthenticationManager，ProviderManager ，AuthenticationProvider …这么多相似的Spring认证类搞得晕头转向，但只要稍微梳理一下就可以理解清楚它们的联系和设计者的用意。AuthenticationManager（接口）是认证相关的核心接口，也是发起认证的出发点，因为在实际需求中，我们可能会允许用户使用用户名+密码登录，同时允许用户使用邮箱+密码，手机号码+密码登录，甚至，可能允许用户使用指纹登录（还有这样的操作？没想到吧），所以说AuthenticationManager一般不直接认证，AuthenticationManager接口的常用实现类ProviderManager 内部会维护一个List<AuthenticationProvider>列表，存放多种认证方式，实际上这是委托者模式的应用（Delegate）。也就是说，核心的认证入口始终只有一个：AuthenticationManager，不同的认证方式：用户名+密码（UsernamePasswordAuthenticationToken），邮箱+密码，手机号码+密码登录则对应了三个AuthenticationProvider。这样一来就好理解多了？。
其中AuthenticationProvider下验证登陆的关键源代码如下：
public Authentication authenticate(Authentication authentication) throws AuthenticationException { Class toTest = authentication.getClass(); AuthenticationException lastException = null; Authentication result = null; boolean debug = logger.isDebugEnabled(); //依次进行验证 for (AuthenticationProvider provider : getProviders()) { if (!provider.supports(toTest)) { continue; } if (debug) { logger.debug("Authentication attempt using " + provider.getClass().getName()); } try { result = provider.authenticate(authentication); // 如果有Authentication信息，则直接返回 if (result != null) { copyDetails(authentication, result); break; } } catch (AccountStatusException e) { prepareException(e, authentication); // SEC-546: Avoid polling additional providers if auth failure is due to // invalid account status throw e; } catch (InternalAuthenticationServiceException e) { prepareException(e, authentication); throw e; } catch (AuthenticationException e) { lastException = e; } } if (result == null && parent != null) { // Allow the parent to try. try { result = parent.authenticate(authentication); } catch (ProviderNotFoundException e) { // ignore as we will throw below if no other exception occurred prior to // calling parent and the parent // may throw ProviderNotFound even though a provider in the child already // handled the request } catch (AuthenticationException e) { lastException = e; } } if (result != null) { if (eraseCredentialsAfterAuthentication && (result instanceof CredentialsContainer)) { //移除密码 ((CredentialsContainer) result).eraseCredentials(); } //发布登录成功事件 eventPublisher.publishAuthenticationSuccess(result); return result; } //执行到此，说明没有认证成功，包装异常信息 if (lastException == null) { lastException = new ProviderNotFoundException(messages.getMessage( "ProviderManager.providerNotFound", new Object[] { toTest.getName() }, "No AuthenticationProvider found for {0}")); } prepareException(lastException, authentication); throw lastException; } 强调一下UserDetails和UserDetailsService
UserDetails
上面不断提到了UserDetails这个接口，它代表了最详细的用户信息，这个接口涵盖了一些必要的用户信息字段，我们一般都需要对它进行必要的扩展。
它和Authentication接口很类似，比如它们都拥有username，authorities，区分他们也是本文的重点内容之一。Authentication的getCredentials()与UserDetails中的getPassword()需要被区分对待，前者是用户提交的密码凭证，后者是用户正确的密码，认证器其实就是对这两者的比对。Authentication中的getAuthorities()实际是由UserDetails的getAuthorities()传递而形成的。还记得Authentication接口中的getUserDetails()方法吗？其中的UserDetails用户详细信息便是经过了AuthenticationProvider之后被填充的。
UserDetailsService
UserDetailsService和AuthenticationProvider两者的职责常常被人们搞混，UserDetailsService只负责从特定的地方加载用户信息，可以是数据库、redis缓存、接口等
核心类图
最后附上核心类图一张
