安全性延伸模組概觀
Reporting Services 安全性延伸模組會啟用使用者或群組的驗證和授權;也就是說,它會讓不同的使用者登入到報表伺服器,並根據其識別執行不同的工作或作業。依預設,Reporting Services 會使用 Windows 架構的驗證延伸模組,此模組使用 Windows 帳戶通訊協定來確認宣稱在系統上具有帳戶之使用者的識別。Reporting Services 會使用以角色為基礎的安全性系統來授權使用者。Reporting Services 以角色為基礎的安全性模型類似於其他技術以角色為基礎的安全性模型。
因為安全性延伸模組是以開放且可延伸的 API 為基礎,所以您可以在 Reporting Services 中建立新的驗證和授權延伸模組。以下是一般安全性延伸模組實作的範例,此實作會使用以表單為基礎的驗證和授權:
如下圖所顯示,驗證和授權的進行方式如下:
使用者使用 URL 來嘗試存取報表管理員,然後被重新導向至針對用戶端應用程式而收集使用者認證的表單。
使用者將認證提交給表單。
使用者認證透過 LogonUser 方法提交給 Reporting Services Web 服務。
Web 服務呼叫客戶所提供的安全性延伸模組,並且確認自訂的安全性授權中具有使用者名稱和密碼。
在進行驗證後,Web 服務會建立驗證 Ticket (也稱為 "Cookie")、管理 Ticket,然後針對報表管理員的首頁確認使用者的角色。
Web 服務將 Cookie 傳回給瀏覽器,並在報表管理員中顯示適當的使用者介面。
在使用者經過驗證後,瀏覽器會以 HTTP 標頭傳送 Cookie 以對報表管理員提出要求。這些要求是用於回應報表管理員應用程式中的使用者動作。
Cookie 會在 HTTP 標頭中,與所要求的使用者作業一起傳送給 Web 服務。
對 Cookie 進行驗證,如為有效,則報表伺服器會從報表伺服器資料庫傳回安全性描述項,以及與所要求作業相關的其他資訊。
如果 Cookie 有效,則報表伺服器會呼叫安全性延伸模組,以檢查是否授權使用者執行特定的作業。
如果使用者已獲得授權,則報表伺服器會執行要求的作業,並將控制項傳回給呼叫者。
在使用者經過驗證後,對報表伺服器的 URL 存取會使用相同的 Cookie。Cookie 會以 HTTP 標頭傳輸。
使用者會繼續在報表伺服器上要求作業,直到工作階段結束。
何時實作安全性延伸模組
我們建議您盡可能使用 Windows 驗證。不過,下列兩個案例可能比較適合 Reporting Services 的自訂驗證和授權:
您具有無法使用 Windows 帳戶的網際網路或外部網路應用程式。
您具有自訂的使用者和角色,而且需要在 Reporting Services 中提供相符的授權配置。