共用方式為

適用於應用程式開發人員的角色型存取控制

  • 發行項

角色型存取控制 (RBAC) 可讓特定使用者或群組具有存取和管理資源的特定權限。 應用程式 RBAC 不同於 Azure 角色型存取控制和 Microsoft Entra 角色存取控制型。 Azure 自訂角色和內建角色都屬於 Azure RBAC，用於協助管理 Azure 資源。 Microsoft Entra RBAC 可用來管理 Microsoft Entra 資源。 本文說明應用程式特定的 RBAC。 如需實作應用程式特定 RBAC 的相關資訊，請參閱如何將應用程式角色新增至您的應用程式，並在權杖中接收這些角色。

角色定義

RBAC 是一個熱門的機制，可在應用程式中強制授權。 當組織使用 RBAC 時，應用程式開發人員會定義角色，而不是授權個別使用者或群組。 管理員可以接著將角色指派給不同的使用者和群組，以控制可以存取內容和功能的人員。

RBAC 可協助應用程式開發人員管理資源及其使用狀況。 RBAC 也可讓應用程式開發人員控制使用者可以存取的應用程式區域。 管理員可以使用「需要使用者指派」屬性來控制哪些使用者可以存取應用程式。 開發人員必須考慮應用程式內的特定使用者，以及使用者可以在應用程式內執行哪些動作。

應用程式開發人員會先在 Microsoft Entra 系統管理中心的應用程式註冊區段內建立角色定義。 角色定義包含針對獲派該角色的使用者所傳回的值。 開發人員接著可以使用此值來實作應用程式邏輯，決定這些使用者可以或不可以在應用程式中執行的動作。

RBAC 選項

考慮在應用程式中包含角色型存取控制授權時，應運用下列指引：

  • 針對應用程式的授權需求，定義必要的角色。
  • 為已驗證的使用者套用、儲存和擷取相關的角色。
  • 根據指派給目前使用者的角色判斷應用程式行為。

定義角色之後，Microsoft 身分識別平台支援多個不同解決方案，可用來為已驗證的使用者套用、儲存和擷取角色資訊。 這些解決方案包括應用程式角色、Microsoft Entra 群組，以及為使用者角色資訊使用自訂資料存放區。

開發人員可為角色指派如何轉譯為應用程式權限，彈性提供自己的實作方式。 此權限解譯可能會牽涉到使用應用程式或相關程式庫平台所提供的中介軟體或其他選項。 應用程式通常會以宣告形式接收使用者角色資訊，而且會根據這些宣告決定使用者權限。

應用程式角色

Microsoft Entra ID 可讓您針對應用程式定義應用程式角色，並將這些角色指派給使用者和其他應用程式。 您指派給使用者或應用程式的角色會定義對應用程式中資源和作業的存取層級。

當 Microsoft Entra ID 針對已驗證的使用者或應用程式發出存取權杖時，其會在存取權杖的 roles 宣告中包含您所指派實體的角色名稱 (使用者或應用程式)。 Web API 之類的應用程式會接收要求中的存取權杖，然後可以根據 roles 宣告中的值制定授權決策。

群組

開發人員也可以使用 Microsoft Entra 群組，在其應用程式中實作 RBAC，其中特定群組中的使用者成員資格會轉譯為其角色成員資格。 當組織使用群組時，權杖會包含群組宣告。 群組宣告會指定租用戶內所有已指派之使用者群組的識別碼。

重要

使用群組時，開發人員必須留意超額宣告概念。 根據預設，如果使用者是超過超額限制的成員 (SAML 權杖為 150、JWT 權杖為 200、如果使用隱含流程則為 6)，Microsoft Entra ID 不會在權杖中發出群組宣告。 相反地，其會在權杖中包含「超額宣告」，以指示權杖的取用者必須查詢 Microsoft Graph API 以擷取使用者的群組成員資格。 如需使用超額宣告的詳細資訊，請參閱存取權杖中的宣告 (機器翻譯)。 雖然群組型指派確實需要 Microsoft Entra ID P1 或 P2 版本，但仍可能只發出指派給應用程式的群組。

自訂資料存放區

應用程式角色和群組都會將使用者指派相關資訊儲存在 Microsoft Entra 目錄中。 另一個開發人員可使用的管理使用者角色資訊選項，就是在自訂資料存放區中維護目錄外的資訊。 例如，在 SQL 資料庫、Azure 資料表儲存體或 Azure Cosmos DB for Table 中。

使用自訂儲存體，可讓開發人員更能自訂和控制如何將角色指派給使用者，以及如何加以呈現。 但更多彈性也帶來更多責任。 例如，目前沒有任何機制可將這項資訊加入從 Microsoft Entra ID 傳回的權杖中。 如果角色資訊保留在自訂資料存放區中，則應用程式必須擷取角色。 擷取角色通常是透過中介軟體中定義的擴充點來完成，而其中介軟體會提供給用來開發應用程式的平台。 開發人員負責妥善保護自訂資料存放區。

使用 Azure AD B2C 自訂原則，您可以與自訂資料存放區互動，並在權杖中包含自訂宣告。

選擇方式

一般而言，應用程式角色是建議的解決方案。 應用程式角色提供最簡單的程式設計模型，而且是針對 RBAC 實作打造。 不過，特定應用程式需求可能會指出其他方法會是更好的解決方案。

開發人員可以使用應用程式角色，控制使用者是否可登入應用程式，或應用程式是否可取得 Web API 的存取權杖。 開發人員想要在應用程式中描述並控制授權的參數時，比起 Microsoft Entra 群組，更偏好使用應用程式角色。 例如，使用群組進行授權的應用程式會在下一個租用戶中斷，因為群組識別碼和名稱可能不同。 使用應用程式角色的應用程式會保持安全無虞。

雖然可使用應用程式角色或群組進行授權，但它們之間的主要差異可能會影響特定情節的最佳解決方案。

應用程式角色 Microsoft Entra 群組 自訂資料存放區
程式設計模型 最簡單。 這些角色專屬於應用程式，並在應用程式註冊時定義。 其會隨著應用程式移動。 較複雜。 可能須考慮租用戶與超額宣告之間的群組識別碼不同。 群組並不專屬於應用程式，而是專屬於 Microsoft Entra 租用戶。 最複雜。 開發人員必須實作儲存和擷取角色資訊的措施。
Microsoft Entra 租用戶之間的角色值是靜態的 是 No 取決於實作。
角色值可用於多個應用程式 否 (除非角色設定在每次應用程式註冊時重複。) Yes Yes
目錄中儲存的資訊 Yes .是 No
資訊透過權杖傳遞 是 (角色宣告) 是 (如有超額，可能須在執行階段擷取「群組宣告」) 否 (透過自訂程式碼在執行階段擷取。)
存留期 存在於目錄的應用程式註冊中。 在移除應用程式註冊時移除。 存在於目錄中。 即使已移除應用程式註冊，仍保持不變。 存在於自訂資料存放區。 未綁定應用程式註冊。

下一步