匯出 (0) 列印
全部展開
本主題尚未接受評分 - 為這個主題評分

在宣告感知 Web 應用程式與服務中的授權

發佈時間: 2011年4月

更新日期: 2011年5月

適用於: Windows Azure

適用對象

  • Microsoft® Windows Azure™ AppFabric Access Control Service (ACS)

  • Windows® Identity Foundation (WIF)

  • ASP.NET

  • Windows Communication Foundation (WCF)

摘要

在信賴憑證者應用程式中,授權會決定允許一個經過驗證的身分識別可以存取的資源,以及它可以對這些資源執行的作業。不當或弱式授權會導致資訊洩漏與資料遭到竄改。此主題簡述使用 ACS 與 WIF 針對宣告感知 ASP.NET Web 應用程式與服務實作授權的可用方法。

目標

  • 列出使用宣告的授權方法。

  • 簡述每個方法的高階設計。

  • 說出每個方法的優點與缺點。

概觀

自 .NET Framework 第一版發行以來,就已經提供實作授權的彈性機制。這個機制以兩個簡易介面為基礎 - IPrincipalIIentityIIentity 的具體實作代表一個經過驗證的使用者。例如,WindowsIdentity 實作代表經過 Active Directory 驗證的使用者,而 GenericIdentity 代表經過自訂驗證方式驗證過的使用者。IPrincipal 的具體實作有助於根據角色存放區使用角色來檢查權限。例如,WindowsPrincipal 會檢查 WindowsIdentity 是否具有 Active Directory 群組的成員資格。它會藉由呼叫 IPrincipal 介面上的 IsInRole 方法來執行這項檢查。根據角色檢查存取稱為「以角色為基礎的存取控制」(RBAC)。RBAC 說明於此主題的<以角色為基礎的存取控制>一節。可以使用宣告來攜帶關於角色的資訊,以支持類似、以角色為基礎的授權機制。

也可以使用宣告來執行除了角色以外其他更豐富的授權決定。宣告幾乎可以根據任何東西 - 年齡、郵遞區號、鞋子尺寸等等。根據任意宣告檢查存取稱為「以宣告為基礎的存取控制」(CBAC) 或以宣告為基礎的授權。以宣告為基礎的授權說明於此主題的<以宣告為基礎的存取控制>一節。

會在應用程式端,而非 ACS 端執行授權檢查。ACS 充當安全性權杖服務 (STS),以簽發將宣告帶到應用程式的權杖。身分識別提供者及 ACS 本身 (選擇性) 可使用其規則引擎,加上宣告來增強權杖的豐富性。當應用程式收到含有宣告的權杖時,它可以剖析權杖、擷取相關的宣告,然後使用 RBAC 或以宣告為基礎的方法來做出授權決定。使用 WIF 可以剖析權杖,使它可以透過一個容易使用的應用程式設計介面 (API) 用於做出授權決定。如需 WIF 的相關資訊,請參閱 WIF SDK (http://go.microsoft.com/fwlink/?LinkID=187481)。當您思考如何在宣告感知應用程式與服務中授權時,請考慮下圖。請注意,一旦成功授權,身分識別提供者會產生一個權杖 (在圖中的 IdP 權杖)。ACS 規則引擎可以轉換 IdP 權杖。ACS 可以新增、移除或變更身分識別提供者簽發的權杖中帶來的宣告。最後會將 ACS 簽發的權杖傳送到應用程式,由 WIF 處理。在 WIF 中會使用 RBAC 或 CBAC 方法完成存取檢查。

ACS v2 WIF 授權

以角色為基礎的存取控制

RBAC 是應用程式根據使用者角色管理與強制實施使用者權限的授權方法。如果使用者具有需要執行一項動作的角色,則會授與存取;否則會拒絕存取。

IPrincipal.IsInRole 方法

若要在宣告感知應用程式中實作 RBAC 方法,請使用 IPrinicpal 介面 IsInRole() 方法,如同您在非宣告感知應用程式中使用的方式一樣。使用 IsInRole() 方法有幾種方式:

  • 明確呼叫 IPrincipal.IsInRole(“Administrator”)。在這個方法中,結果是一個布林值。在您的條件陳述中使用它。可以在程式碼中的任何位置任意使用它。

  • 使用安全性需求 PrincipalPermission.Demand()。在這個方法中,結果是萬一沒有滿足需求時會出現的例外。這應該符合您的例外處理策略。丟出例外相較於汰換布林值花費更多效能。這可以在程式碼中的任何位置使用。

  • 使用宣告式屬性 [PrincipalPermission(SecurityAction.Demand, Role = “Administrator”)]。這個方法稱為宣告式,原因是它用於裝飾方法。在方法的實作內,無法在程式碼區塊中加以使用。其結果是萬一沒有滿足需求時會出現的例外。您應該確定它符合您的例外處理策略。

  • 使用 URL 授權,使用 web.config 中的 <authorization> 區段。當您正在 URL 層級上管理授權時,適合使用這個方法。這是先前提到的所有方法中,最粗略的層級。這個方法的優點是變更是發生在設定檔,表示不應該編譯程式碼來利用那些變更。

以宣告來表示角色

呼叫 IsInRole() 方法時,會進行檢查以確定目前的使用者是否具有該角色。在宣告感知應用程式中,會以在權杖中應該可用的角色宣告類型來表示角色。角色宣告類型是使用下列 URI 來表示:

http://schemas.microsoft.com/ws/2008/06/identity/claims/role

使用角色宣告類型來使權杖更豐富的方法有幾個:

  • 使用 ACS 規則引擎 - 在此案例中,您建立規則的方式是使用 ACS 管理入口網站或 ACS 管理服務來建立宣告轉換規則,以產生特定角色類型的宣告。如需規則與權杖轉換的相關資訊,請參閱規則群組與規則作法:使用規則實作權杖轉換邏輯

  • 使用 ClaimsAuthenticationManager 將任意宣告轉換為宣告角色類型 - ClaimsAuthenticationManager 是 WIF 附隨的元件。它可在啟動應用程式時攔截要求,檢查權杖,以及藉由新增、變更與移除宣告來轉換它們如需如何使用 ClaimsAuthenticationManager 來轉換要求的相關資訊,請參閱作法:使用 WIF 與 ACS 在宣告感知 ASP.NET 應用程式中實作以角色為基礎的存取控制 (RBAC)

  • 使用 samlSecurityTokenRequirement 設定區段將任意宣告對映到角色類型 - 一種宣告式方法,其中只使用設定來完成宣告的轉換,而不需要編碼。

以宣告為基礎的存取控制

CBAC 是一種授權方法,會根據任意邏輯 (使用宣告中可用的資料) 做出授與或拒絕存取的授權決定。請回想 RBAC 的案例,其中唯一使用的宣告是角色類型宣告。使用角色類型宣告來檢查使用者是否屬於特定的角色。若要說明使用以宣告為基礎的授權方法做出授權決定的程序,請考慮下列步驟:

  1. 應用程式收到要求。

  2. 應用程式擷取連入宣告。

  3. 應用程式將宣告傳遞到角色邏輯機制。它可以是在記憶體中的程式碼、對 Web 服務的呼叫、對資料庫的查詢,或可以呼叫精密的規則引擎。

  4. 決定機制會根據宣告計算結果。

  5. 如果結果為 True,則會授與存取,如果為 False,則會拒絕存取。例如,規則可能是等於或大於 21 歲的使用者,住在華盛頓州,並經過 Windows Live® ID 驗證。

ACS 充當安全性權杖服務 (STS) 以簽發攜帶宣告的權杖。您可以控制要簽發的宣告 (包括宣告的類型和值) 方式是使用 ACS 規則引擎。若要深入了解 ACS 規則引擎,請參閱規則群組與規則作法:使用規則實作權杖轉換邏輯。ClaimsAuthorizationManager 是在宣告感知應用程式中實作 CBAC 的關鍵。ClaimsAuthorizationManager 是 WIF 附隨的元件。ClaimsAuthorizationManager 可讓您攔截連入要求並實作由您選擇的任何邏輯,來根據連入要求做出授權決定。這也是一個可延伸的點,從那裡可以在內部進行授權決定,或從應用程式程式碼減少授權決定。需要變更授權邏輯時,這變得很重要。在那種情況下,使用 ClaimsAuthorizationManager 不會影響應用程式的完整性,因此可以降低由於變更造成應用程式錯誤的可能性。若要深入了解如何使用 ClaimsAuthorizationManager 來實作以宣告為基礎的存取控制,請參閱作法:使用 WIF 與 ACS 在宣告感知 ASP.NET 應用程式中實作宣告授權

相關項目

另請參閱

本文對您有任何幫助嗎?
(剩餘 1500 個字元)
感謝您提供意見
Microsoft 正展開一份線上問卷調查,了解您對於 MSDN 網站的看法。 如果您選擇參加,您離開 MSDN 網站時即會顯示線上問卷調查。

您是否想要參加?
顯示:
© 2014 Microsoft. 著作權所有,並保留一切權利。