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

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

角色定義

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

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

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

RBAC 選項

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

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

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

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

應用程式角色

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

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

群組

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

重要

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

自訂資料存放區

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

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

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

選擇方式

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

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

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

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

後續步驟