Tomcat 容器的安全認證和鑑權

大量的 Web 應用都有安全相關的需求，正因如此，Servlet 規範建議容器要有知足這些需求的機制和基礎設施，因此容器要對如下安全特性予以支持：

• 身份驗證：驗證受權用戶的用戶名和密碼
• 資源訪問控制：限制某些資源只容許部分用戶訪問
• 數據完整性：可以證實數據在傳輸過程當中未被第三方修改
• 機密性或數據隱私：傳輸加密（SSL），確保信息只能被信任用戶訪問

本文就以上問題，對 Tomcat 容器提供的認證和鑑權的設計與實現，以及內部單點登陸的原理進行分析。首發於微信公衆號頓悟源碼.

1. 受權

容器和 Web 應用採用的是基於角色的權限訪問控制方式，其中容器須要實現認證和鑑權的功能，而 Web 應用則要實現受權的功能。

在 Servlet 規範中描述了兩種受權方式：聲明式安全和編程式安全。聲明式安全就是在部署描述符中聲明角色、資源訪問權限和認證方式。如下代碼片斷摘自 Tomcat 自帶的 Manager 應用的 web.xml：

<security-constraint> <!-- 安全約束 -->
  <web-resource-collection> <!-- 限制訪問的資源集合 -->
    <web-resource-name>HTML Manager commands</web-resource-name>
    <url-pattern>/html/*</url-pattern>
  </web-resource-collection>
  <auth-constraint><!-- 受權可訪問此資源集合的角色 -->
     <role-name>manager-gui</role-name>
  </auth-constraint>
</security-constraint>

<login-config><!-- 配置驗證方法 -->
  <auth-method>BASIC</auth-method>
  <realm-name>Tomcat Manager Application</realm-name>
</login-config>

<security-role><!-- 定義一個安全角色 -->
  <description>
    The role that is required to access the HTML Manager pages
  </description>
  <role-name>manager-gui</role-name>
</security-role>

這些安全相關的配置，都會在應用部署時，初始化和設置到 StandardContext 對象中。更多詳細的內容可查看規範對部署描述文件的解釋，接下來看 Tomcat 怎麼設計和實現認證及鑑權。

2. 認證和鑑權的設計

Servlet 規範雖然描述了 Web 應用聲明安全約束的機制，但沒有定義容器與關聯用戶和角色信息之間的接口。所以，Tomcat 定義了一個 Realm 接口，用於適配身份驗證的各類信息源。總體設計的類圖以下：

上圖中，包含了各個類的核心方法，關鍵類或接口的做用以下：

• Realm - 譯爲域，域有泛指某種範圍的意思，在這個範圍內存儲着用戶名、密碼、角色和權限，而且提供身份和權限驗證的功能，典型的這個範圍能夠是某個配置文件或數據庫
• CombinedRealm - 內部包含一個或多個 Realm，按配置順序執行身份驗證，任一 Realm 驗證成功，則表示成功驗證
• LockOutRealm - 提供用戶鎖定機制，防止在必定時間段有過多身份驗證失敗的嘗試
• Authenticator - 不一樣身份驗證方法的接口，主要有 BASIC、DIGEST、FORM、SSL 這幾種標準實現
• Principal - 對認證主體的抽象，它包含用戶身份和權限信息
• SingleSignOn - 用於支持容器內多應用的單點登陸功能

2.1 初始化

Realm 是容器的一個可嵌套組件，能夠嵌套在 Engine、Host 和 Context 中，而且子容器能夠覆蓋父容器配置的 Realm。默認的 server.xml 在 Engine 中配置了一個 LockOutRealm 組合域，內部包含一個 UserDatabaseRealm，它從配置的全局資源 conf/tomcat-users.xml 中提取用戶信息。

web.xml 中聲明的安全約束會初始化成對應的 SecurityConstraint、SecurityCollection 和 LoginConfig 對象，並關聯到一個 StandardContext 對象。

在上圖能夠看到，AuthenticatorBase 還實現了 Valve 接口，StandardContext 對象在配置的過程當中，若是發現聲明瞭標準的驗證方法，那麼就會把它加入到本身的 Pipeline 中。

3. 一次請求認證和鑑權過程

Context 在 Tomcat 內部就表明着一個 Web 應用，假設配置使用 BASIC 驗證方法，那麼 Context 內部的 Pipeline 就有 BasicAuthenticator 和 StandardContextValve 兩個閥門，當請求進入 Context 管道時，就首先進行認證和鑑權，方法調用以下：

整個過程的核心代碼就在 AuthenticatorBase 的 invoke 方法中：

public void invoke(Request request, Response response) throws IOException, ServletException {
  LoginConfig config = this.context.getLoginConfig();
  // 0. Session 對象中是否緩存着一個已經進行身份驗證的 Principal
  if (cache) {
    Principal principal = request.getUserPrincipal();
    if (principal == null) {
      Session session = request.getSessionInternal(false);
      if (session != null) {
        principal = session.getPrincipal();
        if (principal != null) {
          request.setAuthType(session.getAuthType());
          request.setUserPrincipal(principal);
        }
      }
    }
  }
  // 對於基於表單登陸，可能位於安全域以外的特殊狀況進行處理
  String contextPath = this.context.getPath();
  String requestURI = request.getDecodedRequestURI();
  if (requestURI.startsWith(contextPath) && requestURI.endsWith(Constants.FORM_ACTION)) {
          return;
      }
  }
  // 獲取安全域對象，默認配置是 LockOutRealm
  Realm realm = this.context.getRealm();
  // 根據請求 URI 嘗試獲取配置的安全約束
  SecurityConstraint [] constraints = realm.findSecurityConstraints(request, this.context);
 
  if ((constraints == null) /* && (!Constants.FORM_METHOD.equals(config.getAuthMethod())) */ ) {
    // 爲 null 表示訪問的資源沒有安全約束，直接訪問下一個閥門
    getNext().invoke(request, response);
    return;
  }
  // 確保受約束的資源不會被 Web 代理或瀏覽器緩存，由於緩存可能會形成安全漏洞
  if (disableProxyCaching && 
      !"POST".equalsIgnoreCase(request.getMethod())) {
      if (securePagesWithPragma) {
          response.setHeader("Pragma", "No-cache");
          response.setHeader("Cache-Control", "no-cache");
      } else {
          response.setHeader("Cache-Control", "private");
      }
      response.setHeader("Expires", DATE_ONE);
  }
  int i;
  // 1. 檢查用戶數據的傳輸安全約束
  if (!realm.hasUserDataPermission(request, response, constraints)) {
    // 驗證失敗
    // Authenticator已經設置了適當的HTTP狀態代碼，所以咱們沒必要作任何特殊的事情
    return;
  }
  // 2. 檢查是否包含受權約束，也就是角色驗證
  boolean authRequired = true;
  for(i=0; i < constraints.length && authRequired; i++) {
    if(!constraints[i].getAuthConstraint()) {
      authRequired = false;
    } else if(!constraints[i].getAllRoles()) {
      String [] roles = constraints[i].findAuthRoles();
      if(roles == null || roles.length == 0) {
        authRequired = false;
      }
    }
  }
  // 3. 驗證用戶名和密碼
  if(authRequired) {
    // authenticate 是一個抽象方法，由不一樣的驗證方法實現
    if (!authenticate(request, response, config)) {
      return;
    } 
  }
  // 4. 驗證用戶是否包含受權的角色
  if (!realm.hasResourcePermission(request, response,constraints,this.context)) {
    return;
  }
  // 5. 已知足任何和全部指定的約束
  getNext().invoke(request, response);
}

另外，AuthenticatorBase 還有一個比較重要的 register() 方法，它會把認證後生成的 Principal 對象設置到當前 Session 中，若是配置了SingleSignOn 單點登陸的閥門，同時把用戶身份、權限信息關聯到 SSO 中。

4. 單點登陸

Tomcat 支持經過一次驗證就能訪問部署在同一個虛擬主機上的全部 Web 應用，可經過如下配置實現：

<Host name="localhost" ...>
  ...
  <Valve className="org.apache.catalina.authenticator.SingleSignOn"/>
  ...
</Host>

Tomcat 的單點登陸是利用 Cookie 實現的：

• 當任一 Web 應用身份驗證成功後，都會把用戶身份信息緩存到 SSO 中，並生成一個名爲 JSESSIONIDSSO 的 Cookie
• 當用戶再次訪問這個主機時，會經過 Cookie 拿出存儲的用戶 token，獲取用戶 Principal 並關聯到 Request 對象中

在單機環境下，沒有問題，在集羣環境下，Tomcat 支持 Session 的複製，那單點登陸相關的信息也會同步複製嗎？後續會繼續分析 Tomcat 集羣的原理和實現。

5. 小結

本文介紹的是 Tomcat 內部實現的登陸認證和權限，而應用程序一般都是經過 Filter 或者自定義的攔截器（如 Spring 的 Interceptor）實現登陸，或者使用第三方安全框架，好比 Shiro，可是原理都差很少。

至此，除了集羣的實現，Tomcat 的核心原理已經分析完畢，接下來將會模擬實現一個簡單的 Tomcat，歡迎關注。