4. 支持同一 RESTful 服務中同時使用兩種身份驗證協議

基本或 Digest 身份驗證可以輕鬆地在 Spring Security 中實現；同時，它們也支持在同一 RESTful Web 服務上的相同 URI 映射中同時使用，這為服務的配置和測試引入了新的複雜性。

4.1. 匿名請求

當基本和 Digest 過濾器在安全鏈中時，一個 匿名請求——一個不包含身份驗證憑據 (Authorization HTTP 標頭) 的請求——由 Spring Security 處理的方式是——兩個身份驗證過濾器將找不到 憑據，並且將繼續執行過濾器鏈的執行。 鑑於請求未被認證，因此會拋出 AccessDeniedException，並在 ExceptionTranslationFilter 中捕獲，從而啓動 Digest 入口點，提示客户端提供憑據。

基本和 Digest 過濾器的責任非常狹窄——如果它們無法識別請求中身份驗證憑據的類型，它們將繼續執行安全過濾器鏈。 這正是 Spring Security 具有配置支持同一 URI 上多種身份驗證協議的靈活性所在。

當請求包含正確的身份驗證憑據——基本或 Digest 協議時，該協議將被正確地使用。 但是，對於匿名請求，客户端只會提示進行 Digest 身份驗證憑據提示。 這是因為 Digest 入口點已配置為 Spring Security 鏈中的主要和唯一入口點；因此，Digest 身份驗證可以被認為是默認的。

4.2. 帶有身份驗證憑據的請求

一個用於 Basic 身份驗證的 帶有身份驗證憑據的請求將通過 Authorization 標頭以 “Basic” 格式開頭來識別。 處理此類請求時，憑據將在基本身份驗證過濾器中進行解碼，並且請求將被授權。 同樣，具有用於 Digest 身份驗證的憑據的請求將使用 “Digest” 格式的 Authorization 標頭。

5. 測試兩種場景

測試將通過創建資源來消耗 REST 服務，無論使用基本身份驗證還是摘要身份驗證：

@Test
public void givenAuthenticatedByBasicAuth_whenAResourceIsCreated_then201IsReceived(){
   // Given
   // When
   Response response = given()
    .auth().preemptive().basic( ADMIN_USERNAME, ADMIN_PASSWORD )
    .contentType( HttpConstants.MIME_JSON ).body( new Foo( randomAlphabetic( 6 ) ) )
    .post( paths.getFooURL() );

   // Then
   assertThat( response.getStatusCode(), is( 201 ) );
}
@Test
public void givenAuthenticatedByDigestAuth_whenAResourceIsCreated_then201IsReceived(){
   // Given
   // When
   Response response = given()
    .auth().digest( ADMIN_USERNAME, ADMIN_PASSWORD )
    .contentType( HttpConstants.MIME_JSON ).body( new Foo( randomAlphabetic( 6 ) ) )
    .post( paths.getFooURL() );

   // Then
   assertThat( response.getStatusCode(), is( 201 ) );
}

注意，使用基本身份驗證的測試會在請求中預先添加憑據，無論服務器是否已發起身份驗證挑戰。這樣做是為了確保服務器無需對客户端發起憑據挑戰，因為如果服務器進行了挑戰，那將是針對 Digest 憑據，因為 Digest 是默認的。

6. 結論

本文介紹了基本認證和 Digest 認證對 RESTful 服務配置和實現的全部內容，主要使用了 Spring Security 命名空間支持以及框架中的一些新功能。