Spring Security系列之體系結構概述(一)

蔣老溼發表於2018-12-10

Spring Security系列之體系結構概述(一)
文章來源
這篇文章是我Spring Security系列的第一篇,主要是根據Spring Security文件選擇性翻譯整理而成的一個架構概覽,配合自己的一些註釋方便大家理解。寫作本系列文章時,參考版本為Spring Security 4.2.3.RELEASE。

核心元件

這一節主要介紹一些在Spring Security中常見且核心的Java類,它們之間的依賴,構建起了整個框架。想要理解整個架構,最起碼得對這些類眼熟。

SecurityContextHolder

SecurityContextHolder用於儲存安全上下文(security context)的資訊。當前操作的使用者是誰,該使用者是否已經被認證,他擁有哪些角色許可權…這些都被儲存在SecurityContextHolder中。SecurityContextHolder預設使用ThreadLocal 策略來儲存認證資訊。看到ThreadLocal 也就意味著,這是一種與執行緒繫結的策略。Spring Security在使用者登入時自動繫結認證資訊到當前執行緒,在使用者退出時,自動清除當前執行緒的認證資訊。但這一切的前提,是你在web場景下使用Spring Security,而如果是Swing介面,Spring也提供了支援,SecurityContextHolder的策略則需要被替換,鑑於我的初衷是基於web來介紹Spring Security,所以這裡以及後續,非web的相關的內容都一筆帶過。

獲取當前使用者的資訊 因為身份資訊是與執行緒繫結的,所以可以在程式的任何地方使用靜態方法獲取使用者資訊。一個典型的獲取當前登入使用者的姓名的例子如下所示:

Object principal = SecurityContextHolder.getContext().getAuthentication().getPrincipal();

if (principal instanceof UserDetails) {
String username = ((UserDetails)principal).getUsername();
} else {
String username = principal.toString();
}
複製程式碼

getAuthentication()返回了認證資訊,再次getPrincipal()返回了身份資訊,UserDetails便是Spring對身份資訊封裝的一個介面。Authentication和UserDetails的介紹在下面的小節具體講解,本節重要的內容是介紹SecurityContextHolder這個容器。

Authentication

先看看這個介面的原始碼長什麼樣:

package org.springframework.security.core; # <1>

public interface Authentication extends Principal, Serializable { # <1>
    Collection<? extends GrantedAuthority> getAuthorities(); # <2>

    Object getCredentials();# <2>

    Object getDetails();# <2>

    Object getPrincipal();# <2>

    boolean isAuthenticated();# <2>

    void setAuthenticated(boolean var1) throws IllegalArgumentException;
}
複製程式碼
  1. <1> Authentication是spring security包中的介面,直接繼承自Principal類,而Principal是位於java.security包中的。可以見得,Authentication在spring security中是最高階別的身份/認證的抽象。
  2. <2> 由這個頂級介面,我們可以得到使用者擁有的許可權資訊列表,密碼,使用者細節資訊,使用者身份資訊,認證資訊。

還記得SecurityContextHolder節中,authentication.getPrincipal()返回了一個Object,我們將Principal強轉成了Spring Security中最常用的UserDetails,這在Spring Security中非常常見,介面返回Object,使用instanceof判斷型別,強轉成對應的具體實現類。介面詳細解讀如下:

  • getAuthorities(),許可權資訊列表,預設是GrantedAuthority介面的一些實現類,通常是代表許可權資訊的一系列字串。
  • getCredentials(),密碼資訊,使用者輸入的密碼字串,在認證過後通常會被移除,用於保障安全。
  • getDetails(),細節資訊,web應用中的實現介面通常為 WebAuthenticationDetails,它記錄了訪問者的ip地址和sessionId的值。
  • getPrincipal(),敲黑板!!!最重要的身份資訊,大部分情況下返回的是UserDetails介面的實現類,也是框架中的常用介面之一。UserDetails介面將會在下面的小節重點介紹。

Spring Security是如何完成身份認證的?

  1. 使用者名稱和密碼被過濾器獲取到,封裝成Authentication,通常情況下是UsernamePasswordAuthenticationToken這個實現類。
  2. AuthenticationManager 身份管理器負責驗證這個Authentication
  3. 認證成功後,AuthenticationManager身份管理器返回一個被填充滿了資訊的(包括上面提到的許可權資訊,身份資訊,細節資訊,但密碼通常會被移除)Authentication例項。
  4. SecurityContextHolder安全上下文容器將第3步填充了資訊的Authentication,通過SecurityContextHolder.getContext().setAuthentication(…)方法,設定到其中。

這是一個抽象的認證流程,而整個過程中,如果不糾結於細節,其實只剩下一個AuthenticationManager 是我們沒有接觸過的了,這個身份管理器我們在後面的小節介紹。將上述的流程轉換成程式碼,便是如下的流程:

public class AuthenticationExample {
private static AuthenticationManager am = new SampleAuthenticationManager();

public static void main(String[] args) throws Exception {
    BufferedReader in = new BufferedReader(new InputStreamReader(System.in));

    while(true) {
    System.out.println("Please enter your username:");
    String name = in.readLine();
    System.out.println("Please enter your password:");
    String password = in.readLine();
    try {
        Authentication request = new UsernamePasswordAuthenticationToken(name, password);
        Authentication result = am.authenticate(request);
        SecurityContextHolder.getContext().setAuthentication(result);
        break;
    } catch(AuthenticationException e) {
        System.out.println("Authentication failed: " + e.getMessage());
    }
    }
    System.out.println("Successfully authenticated. Security context contains: " +
            SecurityContextHolder.getContext().getAuthentication());
}
}

class SampleAuthenticationManager implements AuthenticationManager {
static final List<GrantedAuthority> AUTHORITIES = new ArrayList<GrantedAuthority>();

static {
    AUTHORITIES.add(new SimpleGrantedAuthority("ROLE_USER"));
}

public Authentication authenticate(Authentication auth) throws AuthenticationException {
    if (auth.getName().equals(auth.getCredentials())) {
    return new UsernamePasswordAuthenticationToken(auth.getName(),
        auth.getCredentials(), AUTHORITIES);
    }
    throw new BadCredentialsException("Bad Credentials");
}
}
複製程式碼

注意:上述這段程式碼只是為了讓大家瞭解Spring Security的工作流程而寫的,不是什麼原始碼。在實際使用中,整個流程會變得更加的複雜,但是基本思想,和上述程式碼如出一轍。

AuthenticationManager

初次接觸Spring Security的朋友相信會被AuthenticationManager,ProviderManager ,AuthenticationProvider …這麼多相似的Spring認證類搞得暈頭轉向,但只要稍微梳理一下就可以理解清楚它們的聯絡和設計者的用意。AuthenticationManager(介面)是認證相關的核心介面,也是發起認證的出發點,因為在實際需求中,我們可能會允許使用者使用使用者名稱+密碼登入,同時允許使用者使用郵箱+密碼,手機號碼+密碼登入,甚至,可能允許使用者使用指紋登入(還有這樣的操作?沒想到吧),所以說AuthenticationManager一般不直接認證,AuthenticationManager介面的常用實現類ProviderManager 內部會維護一個 List<AuthenticationProvider> 列表,存放多種認證方式,實際上這是委託者模式的應用(Delegate)。也就是說,核心的認證入口始終只有一個:AuthenticationManager,不同的認證方式:使用者名稱+密碼(UsernamePasswordAuthenticationToken),郵箱+密碼,手機號碼+密碼登入則對應了三個AuthenticationProvider。這樣一來四不四就好理解多了?熟悉shiro的朋友可以把AuthenticationProvider理解成Realm。在預設策略下,只需要通過一個AuthenticationProvider的認證,即可被認為是登入成功。

例子:只保留了關鍵認證部分的ProviderManager原始碼:

public class ProviderManager implements AuthenticationManager, MessageSourceAware,
        InitializingBean {

    // 維護一個AuthenticationProvider列表
    private List<AuthenticationProvider> providers = Collections.emptyList();

    public Authentication authenticate(Authentication authentication)
          throws AuthenticationException {
       Class<? extends Authentication> toTest = authentication.getClass();
       AuthenticationException lastException = null;
       Authentication result = null;

       // 依次認證
       for (AuthenticationProvider provider : getProviders()) {
          if (!provider.supports(toTest)) {
             continue;
          }
          try {
             result = provider.authenticate(authentication);

             if (result != null) {
                copyDetails(authentication, result);
                break;
             }
          }
          ...
          catch (AuthenticationException e) {
             lastException = e;
          }
       }
       // 如果有Authentication資訊,則直接返回
       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;
    }
}
複製程式碼

ProviderManager 中的List<AuthenticationProvider>,會依照次序去認證,認證成功則立即返回,若認證失敗則返回null,下一個AuthenticationProvider會繼續嘗試認證,如果所有認證器都無法認證成功,則ProviderManager會丟擲一個ProviderNotFoundException異常。

到這裡,如果不糾結於AuthenticationProvider的實現細節以及安全相關的過濾器,認證相關的核心類其實都已經介紹完畢了:身份資訊的存放容器SecurityContextHolder,身份資訊的抽象Authentication,身份認證器AuthenticationManager及其認證流程。姑且在這裡做一個分隔線。下面來介紹下AuthenticationProvider介面的具體實現

DaoAuthenticationProvider

AuthenticationProvider最最最常用的一個實現便是DaoAuthenticationProvider。顧名思義,Dao正是資料訪問層的縮寫,也暗示了這個身份認證器的實現思路。由於本文是一個Overview,姑且只給出其結構圖:

Spring Security系列之體系結構概述(一)
按照我們最直觀的思路,怎麼去認證一個使用者呢?使用者前臺提交了使用者名稱和密碼,而資料庫中儲存了使用者名稱和密碼,認證便是負責比對同一個使用者名稱,提交的密碼和儲存的密碼是否相同便是了。在Spring Security中。提交的使用者名稱和密碼,被封裝成了UsernamePasswordAuthenticationToken,而根據使用者名稱載入使用者的任務則是交給了UserDetailsService,在DaoAuthenticationProvider中,對應的方法便是retrieveUser,雖然有兩個引數,但是retrieveUser只有第一個引數起主要作用,返回一個UserDetails。還需要完成UsernamePasswordAuthenticationToken和UserDetails密碼的比對,這便是交給additionalAuthenticationChecks方法完成的,如果這個void方法沒有拋異常,則認為比對成功。比對密碼的過程,用到了PasswordEncoder和SaltSource,密碼加密和鹽的概念相信不用我贅述了,它們為保障安全而設計,都是比較基礎的概念。

如果你已經被這些概念搞得暈頭轉向了,不妨這麼理解DaoAuthenticationProvider:它獲取使用者提交的使用者名稱和密碼,比對其正確性,如果正確,返回一個資料庫中的使用者資訊(假設使用者資訊被儲存在資料庫中)。

UserDetails與UserDetailsService

上面不斷提到了UserDetails這個介面,它代表了最詳細的使用者資訊,這個介面涵蓋了一些必要的使用者資訊欄位,具體的實現類對它進行了擴充套件

public interface UserDetails extends Serializable {

   Collection<? extends GrantedAuthority> getAuthorities();

   String getPassword();

   String getUsername();

   boolean isAccountNonExpired();

   boolean isAccountNonLocked();

   boolean isCredentialsNonExpired();

   boolean isEnabled();
}
複製程式碼

它和Authentication介面很類似,比如它們都擁有username,authorities,區分他們也是本文的重點內容之一。Authentication的getCredentials()與UserDetails中的getPassword()需要被區分對待,前者是使用者提交的密碼憑證,後者是使用者正確的密碼,認證器其實就是對這兩者的比對。Authentication中的getAuthorities()實際是由UserDetails的getAuthorities()傳遞而形成的。還記得Authentication介面中的getUserDetails()方法嗎?其中的UserDetails使用者詳細資訊便是經過了AuthenticationProvider之後被填充的。

public interface UserDetailsService {
   UserDetails loadUserByUsername(String username) throws UsernameNotFoundException;
}
複製程式碼

UserDetailsService和AuthenticationProvider兩者的職責常常被人們搞混,關於他們的問題在文件的FAQ和issues中屢見不鮮。記住一點即可,敲黑板!!!UserDetailsService只負責從特定的地方(通常是資料庫)載入使用者資訊,僅此而已,記住這一點,可以避免走很多彎路。UserDetailsService常見的實現類有JdbcDaoImpl,InMemoryUserDetailsManager,前者從資料庫載入使用者,後者從記憶體中載入使用者,也可以自己實現UserDetailsService,通常這更加靈活。

架構概覽圖

為了更加形象的理解上述我介紹的這些核心類,附上一張按照我的理解,所畫出Spring Security的一張非典型的UML圖

Spring Security系列之體系結構概述(一)
如果對Spring Security的這些概念感到理解不能,不用擔心,因為這是Architecture First導致的必然結果,先過個眼熟。後續的文章會秉持Code First的理念,陸續詳細地講解這些實現類的使用場景,原始碼分析,以及最基本的:如何配置Spring Security,在後面的文章中可以不時翻看這篇文章,找到具體的類在整個架構中所處的位置,這也是本篇文章的定位。另外,一些Spring Security的過濾器還未囊括在架構概覽中,如將表單資訊包裝成UsernamePasswordAuthenticationToken的過濾器,考慮到這些雖然也是架構的一部分,但是真正重寫他們的可能性較小,所以打算放到後面的章節講解。

Spring Security系列之體系結構概述(一)

相關文章