在宣告感知 Web 應用程式與服務中的授權
更新日期：2015 年 6 月 19 日
適用對象：Azure
套用至
Microsoft Azure Active Directory 存取控制服務 (也稱為「存取控制服務」或 ACS)
Windows® Identity Foundation (WIF)
ASP.NET
Windows Communication Foundation (WCF)
總結
在信賴憑證者應用程式中，授權會判斷哪些是已驗證的識別可以存取的資源，以及可以針對這些資源執行哪些作業。 不適當或弱式授權會導致資訊洩露以及資料遭竄改。 本主題概述使用 ACS 和 WIF 實作宣告感知 ASP.NET Web 應用程式和服務的可用方法。
目標
列出使用宣告的授權方法。
簡述每個方法的高階設計。
說出每個方法的優點與缺點。
概觀
從第一版 .NET Framework 開始，就提供了彈性的授權實作機制。 這個機制以兩個簡易介面為基礎 - IPrincipal 和 IIentity。 IIentity 的具體實作代表一個經過驗證的使用者。 例如， WindowsIdentity 實作代表 Active Directory 驗證的使用者， 而 GenericIdentity 代表由自訂驗證驗證驗證的使用者。 IPrincipal 的具體實作有助於根據角色存放區使用角色來檢查權限。 例如，WindowsPrincipal 會檢查 WindowsIdentity 是否擁有 Active Directory 中各群組的成員資格。 它會藉由呼叫 IPrincipal 介面上的 IsInRole 方法來執行這項檢查。 根據角色來檢查存取權限的做法稱為角色型存取控制 (RBAC)。 RBAC 說明於此主題的＜以角色為基礎的存取控制＞一節。 宣告可用來攜帶角色相關資訊，以支援熟悉且以角色為基礎的授權機制。
也可以使用宣告來執行除了角色以外其他更豐富的授權決定。 宣告幾乎可以根據任何東西 - 年齡、郵遞區號、鞋子尺寸等等。 根據任意宣告檢查存取稱為「以宣告為基礎的存取控制」(CBAC) 或以宣告為基礎的授權。 以宣告為基礎的授權說明於此主題的＜以宣告為基礎的存取控制＞一節。
授權檢查是在應用程式端執行，而不是在 ACS 端執行。 ACS 做為安全性權杖服務， (STS) 發出宣告給應用程式的權杖。 權杖會透過識別提供者的宣告來擴充，並選擇性地由 ACS 本身使用其規則引擎來擴充。 當應用程式收到含有宣告的權杖時，它可以剖析權杖、擷取相關的宣告，然後使用 RBAC 或以宣告為基礎的方法來做出授權決定。 使用 WIF 可以剖析權杖，使它可以透過一個容易使用的應用程式設計介面 (API) 用於做出授權決定。 如需 WIF 的詳細資訊，請參閱 WIF SDK (https://go.microsoft.com/fwlink/?LinkID=187481) 。 當您思考如何在宣告感知應用程式與服務中授權時，請考慮下圖。 請注意，一旦成功授權，身分識別提供者會產生一個權杖 (在圖中的 IdP 權杖)。 IDP 權杖可由 ACS 規則引擎轉換。 ACS 可以新增、移除或變更身分識別提供者所發出權杖中的宣告。 最後，ACS 發出的權杖會傳送至應用程式，並由 WIF 處理。 在 WIF 中會使用 RBAC 或 CBAC 方法完成存取檢查。
.gif "ACS v2 WIF Authorization")
角色型存取控制
RBAC 是一種授權方式，應用程式會根據使用者角色來管理和落實使用者權限。 如果使用者有執行動作所需的角色，應用程式就會授與存取權限，否則會拒絕存取。
IPrincipal.IsInRole 方法
若要在宣告感知應用程式中實作 RBAC 方法，請使用 IPrinicpal 介面 IsInRole() 方法，如同您在非宣告感知應用程式中使用的方式一樣。 使用 IsInRole() 方法有幾種方式：
明確呼叫 IPrincipal.IsInRole(“Administrator”)。 如果使用這種方式，結果會是布林值。 因此，您可以在條件陳述式中使用。 使用時，它可以位於程式碼中的任意位置。
使用安全性需求 PrincipalPermission.Demand()。 使用這種方式時，如果無法滿足要求，結果會發生例外狀況。 因此，您可以在例外狀況處理策略中使用這種方式。 丟出例外相較於汰換布林值花費更多效能。 使用時，它可以位於程式碼中的任意位置。
使用宣告式屬性 [PrincipalPermission(SecurityAction.Demand, Role = “Administrator”)]。 這種方式是用來裝飾方法，因此稱為宣告式。 它不能在方法實作內的程式碼區塊中使用。 如果無法滿足要求，結果會發生例外狀況。 因此，您應該確認可以在例外狀況處理策略中使用這種方式。
使用 URL 授權，使用<web.config中的授權 >區段。當您在 URL 層級上管理授權時，這個方法很適合。 與先前提及的方式相比，這種方式是最粗糙的。 其優點在於我們只要變更組態檔內容即可，也就是說，我們不必編譯程式碼就可以獲得變更的好處。
將角色表示為宣告
呼叫 IsInRole() 方法時，會進行檢查以確定目前的使用者是否具有該角色。 在宣告感知應用程式中，角色是依角色宣告類型表示，而該類型可以從權杖中取得。 角色宣告類型是使用下列 URI 來表示：
https://schemas.microsoft.com/ws/2008/06/identity/claims/role
下列幾種方式都可以利用角色宣告類型來增加權杖內容：
使用 ACS 規則引擎— 在此情況下，您會使用 ACS 管理入口網站或 ACS 管理服務來建立宣告轉換規則，以產生特定角色類型的宣告。 如需規則和權杖轉換的詳細資訊，請參閱 規則群組和規則 和 如何：使用規則實作權杖轉換邏輯。
使用 ClaimsAuthenticationManager 將任意宣告轉換為宣告角色類型 - ClaimsAuthenticationManager 是 WIF 附隨的元件。 可允許使用者在啟動應用程式時攔截要求，並且檢查權杖以及利用新增、變更或移除宣告來轉換權杖。 如需如何使用 ClaimsAuthenticationManager 轉換宣告的詳細資訊，請參閱如何：在宣告感知 ASP.NET 應用程式中使用 WIF 和 ACS 實作角色型存取控制 (RBAC)
使用 samlSecurityTokenRequirement 設定區段將任意宣告對映到角色類型 - 一種宣告式方法，其中只使用設定來完成宣告的轉換，而不需要編碼。
以宣告為基礎的存取控制
CBAC 是一種授權方法，會根據任意邏輯 (使用宣告中可用的資料) 做出授與或拒絕存取的授權決定。 請回想 RBAC 的情況是將宣告當做角色類型宣告， 並使用角色型別宣告檢查使用者是否屬於特定角色。 下列步驟示範使用宣告式授權方式的授權決策制定流程：
應用程式收到要求。
應用程式擷取連入宣告。
應用程式將宣告傳遞給決策邏輯機制。 它可以是在記憶體中的程式碼、對 Web 服務的呼叫、對資料庫的查詢，或可以呼叫精密的規則引擎。
決策機制根據宣告計算結果。
如果結果為 true 則授與存取權限，如果為 false 則拒絕存取。 例如，此規則可能是使用者年齡為 21 或更新版本、位於華盛頓州，且由Windows Live ID (Microsoft 帳戶) 進行驗證。
ACS 可作為發行具有宣告之權杖的 STS。 您可以使用 ACS 規則引擎來控制發出宣告的類型和值。 若要深入瞭解 ACS 規則引擎，請參閱 規則群組和規則 和 如何：使用規則實作權杖轉換邏輯。 ClaimsAuthorizationManager 是在宣告感知應用程式中實作 CBAC 的關鍵。 ClaimsAuthorizationManager 是 WIF 附隨的元件。 可讓您擷取傳入要求並實作您選擇的邏輯，根據傳入宣告制定授權決策。 這也是一個可延伸的點，從那裡可以在內部進行授權決定，或從應用程式程式碼減少授權決定。 如果必須變更授權邏輯，這就變得很重要。 在這種情況下，使用 ClaimsAuthorizationManager 既不會影響應用程式的完整性，還可以降低變更結果導致應用程式錯誤的可能性。 若要深入瞭解如何使用 ClaimsAuthorizationManager 來實作宣告型存取控制，請參閱如何：使用 WIF 和 ACS 在宣告感知 ASP.NET 應用程式中實作宣告授權。