安全性延伸模組概觀 - Reporting Services (SSRS)

Reporting Services 安全性延伸模組可啟用使用者或群組的驗證和授權;也就是說,它可讓不同的使用者登入報表伺服器,並根據其身分識別執行不同的工作或作業。 依預設,Reporting Services 會使用 Windows 架構的驗證延伸模組,此模組使用 Windows 帳戶通訊協定來確認宣稱在系統上具有帳戶之使用者的身分識別。 Reporting Services 會使用角色型安全性系統來授權使用者。 Reporting Services 的角色型安全性模型類似於其他技術的角色型安全性模型。

因為安全性延伸模組是以開放且可延伸的 API 為基礎,所以您可以在 Reporting Services 中建立新的驗證和授權延伸模組。 下列範例示範使用表單型驗證和授權的一般安全性延伸模組實作:

Screenshot of the Reporting Services security extension process.

如下圖所顯示,驗證和授權的進行方式如下:

  1. 使用者使用 URL 來嘗試存取入口網站,然後被重新導向至針對用戶端應用程式收集使用者認證的表單。

  2. 使用者將認證提交給表單。

  3. 使用者認證透過 LogonUser 方法提交給 Reporting Services Web 服務。

  4. Web 服務呼叫客戶所提供的安全性延伸模組,並且確認自訂的安全性授權中具有使用者名稱和密碼。

  5. 在進行驗證後,Web 服務會建立驗證票證 (也稱為 "Cookie")、管理票證,然後針對入口網站的首頁確認使用者的角色。

  6. Web 服務將 Cookie 傳回給瀏覽器,並在入口網站中顯示適當的使用者介面。

  7. 在使用者經過驗證後,瀏覽器會以 HTTP 標頭傳送 Cookie 以對入口網站提出要求。 這些要求是用於回應入口網站中的使用者動作。

  8. Cookie 會在 HTTP 標頭中,與所要求的使用者作業一起傳送給 Web 服務。

  9. Cookie 會經過驗證,如果 Cookie 有效,報表伺服器會從報表伺服器資料庫傳回與所要求作業相關的安全性描述元和其他資訊。

  10. 如果 Cookie 有效,則報表伺服器會呼叫安全性延伸模組,以檢查是否授權使用者執行特定的作業。

  11. 如果使用者已獲得授權,則報表伺服器會執行要求的作業,並將控制項傳回給呼叫者。

  12. 在使用者經過驗證後,對報表伺服器的 URL 存取會使用相同的 Cookie。 Cookie 會以 HTTP 標頭傳輸。

  13. 用戶會繼續要求報表伺服器上的作業,直到會話結束為止。

何時實作安全性延伸模組

我們建議您盡可能使用 Windows 驗證。 不過,在下列兩種情況下,Reporting Services 的自定義驗證和授權可能適用:

  • 您有無法使用 Windows 帳戶的因特網或外部網路應用程式。

  • 您具有自訂的使用者和角色,而且需要在 Reporting Services 中提供相符的授權配置。