共用方式為

Reporting Services 中的驗證

  • 發行項

驗證是建立使用者對識別的權限之程序。 您可以使用許多技術來驗證使用者。 最常見的方式是使用密碼。 例如，當您實作窗體驗證時，您想要實作來查詢使用者是否有認證（通常是由要求登入名稱和密碼的某些介面），然後針對數據存放區驗證使用者，例如資料庫數據表或組態檔。 如果無法驗證認證，驗證程式會失敗，且使用者假設匿名身分識別。

Reporting Services 中的自訂驗證

在 Reporting Services 中，Windows 作業系統會透過整合式安全性，或是明確接收與驗證使用者認證，來處理使用者的驗證。 自定義驗證可以在 Reporting Services 中開發，以支援更多驗證配置。 這項支援可透過安全性延伸模組介面 IAuthenticationExtension2進行。 所有的延伸模組都會針對報表伺服器所部署和使用的任何延伸模組，自 IExtension 基底介面繼承。 IExtension、 和 IAuthenticationExtension2是命名空間的成員 Microsoft.ReportingServices.Interfaces 。

在 Reporting Services 中對報表伺服器進行驗證的主要方式為 LogonUser 方法。 Reporting Services Web 服務的這個成員，可用以將使用者認證傳遞給報告伺服器以供驗證。 您的基礎安全性延伸模組會實作 IAuthenticationExtension2.LogonUser，以包含自訂驗證程式碼。 在表單驗證範例中，LogonUser 會針對提供的認證以及資料庫中的自訂使用者存放區執行驗證檢查。 LogonUser 的實作範例看起來像這樣：

public bool LogonUser(string userName, string password, string authority)  
{  
   return AuthenticationUtilities.VerifyPassword(userName, password);  
}

下列範例函數是用以驗證提供的認證：

  
internal static bool VerifyPassword(string suppliedUserName,  
   string suppliedPassword)  
{   
   bool passwordMatch = false;  
   // Get the salt and pwd from the database based on the user name.  
   // See "How To: Use DPAPI (Machine Store) from ASP.NET," "How To:  
   // Use DPAPI (User Store) from Enterprise Services," and "How To:  
   // Create a DPAPI Library" for more information about how to use  
   // DPAPI to securely store connection strings.  
   SqlConnection conn = new SqlConnection(  
      "Server=localhost;" +   
      "Integrated Security=SSPI;" +  
      "database=UserAccounts");  
   SqlCommand cmd = new SqlCommand("LookupUser", conn);  
   cmd.CommandType = CommandType.StoredProcedure;  
  
   SqlParameter sqlParam = cmd.Parameters.Add("@userName",  
       SqlDbType.VarChar,  
       255);  
   sqlParam.Value = suppliedUserName;  
   try  
   {  
      conn.Open();  
      SqlDataReader reader = cmd.ExecuteReader();  
      reader.Read(); // Advance to the one and only row  
      // Return output parameters from returned data stream  
      string dbPasswordHash = reader.GetString(0);  
      string salt = reader.GetString(1);  
      reader.Close();  
      // Now take the salt and the password entered by the user  
      // and concatenate them together.  
      string passwordAndSalt = String.Concat(suppliedPassword, salt);  
      // Now hash them  
      string hashedPasswordAndSalt =  
         FormsAuthentication.HashPasswordForStoringInConfigFile(  
         passwordAndSalt,  
         "SHA1");  
      // Now verify them. Returns true if they are equal.  
      passwordMatch = hashedPasswordAndSalt.Equals(dbPasswordHash);  
   }  
   catch (Exception ex)  
   {  
       throw new Exception("Exception verifying password. " +  
          ex.Message);  
   }  
   finally  
   {  
       conn.Close();  
   }  
   return passwordMatch;  
}

驗證流程

Reporting Services Web 服務提供自訂驗證延伸模組，以允許入口網站與報表伺服器的表單驗證。

Reporting Services Web 服務的 LogonUser 方法是用以將認證提交到報表伺服器以進行驗證。 Web 服務會使用 HTTP 標頭，將驗證票證（稱為「Cookie」）從伺服器傳遞至用戶端，以取得已驗證的登入要求。

下圖描述當應用程式是使用報表伺服器來部署，而該報表伺服器是設定成使用自訂驗證延伸模組時，在 Web 服務中驗證使用者的方法。

Screenshot of the Reporting Services security authentication flow.

如圖 2 所示，驗證程序如下：

  1. 用戶端應用程式會呼叫 Web 服務的 LogonUser 方法來驗證使用者。

  2. Web 服務會呼叫安全性延伸模組的 LogonUser 方法；特別是，實作 IAuthenticationExtension2 的類別。

  3. LogonUser 的實作會在使用者存放區或是安全性授權中，驗證使用者名稱與密碼。

  4. 一旦成功驗證，Web 服務會為工作階段建立 Cookie 並管理它。

  5. Web 服務會將驗證 Ticket 傳回 HTTP 標頭上的呼叫應用程式。

當 Web 服務透過安全性延伸模組成功地驗證使用者時，它會產生用於後續要求的 Cookie。 Cookie 可能不會保存在自定義安全性授權單位內，因為報表伺服器沒有安全性授權單位。 Cookie 會從 LogonUser Web 服務方法傳回，而且是用於後續的 Web 服務方法呼叫和 URL 存取中。

注意

為了避免在傳輸期間破壞 Cookie，應該使用傳輸層安全性 (TLS) (先前稱為安全通訊端層 (SSL)) 加密，安全地傳輸從 LogonUser 傳回的驗證 Cookie。

在已安裝自訂安全性延伸模組的情況下，如果您透過 URL 來存取報表伺服器，Internet Information Services (IIS) 與 ASP.NET 會自動管理驗證票證的傳輸。 如果您要透過SOAP API存取報表伺服器，則 Proxy 類別的實作必須包含額外支援來管理驗證票證。 如需有關使用 SOAP API 以及管理驗證 Ticket 的詳細資訊，請參閱「透過自訂安全性使用 Web 服務」。

表單驗證

表單驗證是一種 ASP.NET 驗證類型，它會將未驗證的使用者導向 HTML 表單。 一旦使用者提供認證，系統會發出包含驗證 Ticket 的 Cookie。 在稍後的要求中，系統會先檢查 Cookie，以查看報表伺服器是否已驗證使用者。

Reporting Services 可透過 Reporting Services API 使用可用的安全性擴充介面進行擴充，以支援表單驗證。 如果您擴充 Reporting Services 來使用表單驗證，請針對所有報表伺服器的通訊使用傳輸層安全性 (TLS) (先前稱為安全通訊端層 (SSL))，以防止惡意的使用者存取其他使用者的 Cookie。 TLS 允許用戶端和報表伺服器驗證彼此，並確保沒有其他的電腦可以讀取兩部電腦之間的通訊內容。 透過 TLS 連線從用戶端傳送的所有資料都會加密，讓惡意使用者無法攔截傳送至報表伺服器的密碼或數據。

窗體驗證的實作是為了支援 Windows 以外的平臺的帳戶和驗證。 對於要求存取報表伺服器的使用者會顯示圖形介面，而且會將提供的認證提交到安全性授權以進行驗證。

表單驗證需要該人員在場以輸入認證。 對於直接與 Reporting Services Web 服務通訊的自動執行應用程式，必須將表單驗證與自訂驗證配置結合。

在下列情況下，表單驗證適用於 Reporting Services：

  • 您需要儲存和驗證沒有 Microsoft Windows 帳戶的使用者，以及

  • 您必須提供您自己的使用者介面窗體，做為網站上不同頁面之間的登入頁面。

撰寫支援窗體驗證的自訂安全性延伸模組時，請考慮下列幾點：

  • 如果您使用表單驗證，必須在 Internet Information Services (IIS) 中的報表伺服器虛擬目錄上啟用匿名存取。

  • ASP.NET 驗證必須設定為 [表單]。 您在 Web.config 檔案中為報表伺服器設定 ASP.NET 驗證。

  • Reporting Services 可以使用 Windows 驗證或是自訂驗證，來驗證和授權使用者，但並不能同時使用這兩者。 Reporting Services 不支持同時使用多個安全性延伸模組。

相關內容