案例使用 - 使用 Microsoft Entra ID 來保護 SAP 平台和應用程式的存取
本文件提供使用 Microsoft Entra ID 作為 SAP 雲端識別服務的主要使用者驗證服務時， SAP 平台和應用程式的技術設計和設定建議。 SAP 雲端識別服務包含身分識別驗證、身分識別佈建、身分識別目錄及授權管理。 請參閱 Microsoft Entra 單一登入 (SSO) 與 SAP 雲端識別服務整合教學課程，以詳細了解驗證的初始設定。 如需佈建和其他案例的詳細資訊，請參閱規劃部署 Microsoft Entra 以使用 SAP 來源和目標應用程式進行使用者佈建以及管理 SAP 應用程式的存取。
本指南使用的詞彙
| 縮寫 | 描述 |
|---|---|
| BTP | SAP 商業技術平台是針對雲端中 SAP 應用程式最佳化的創新平台。 此處探討的大部分 SAP 技術都屬於 BTP。 正式名稱為 SAP Cloud Platform 的產品也都屬於 SAP BTP。 |
| IAS | SAP 雲端識別服務 - Identity Authentication，是 SAP 雲端識別服務的元件，是一項雲端服務，可用於在 SAP 雲端和內部部署應用程式中進行驗證、單一登入和使用者管理。 IAS 可協助使用者向自己的 SAP BTP 服務執行個體進行驗證，作為與 Microsoft Entra 單一登入整合的 Proxy。 |
| IPS | SAP 雲端識別服務 - 身分識別佈建，是 SAP 雲端識別服務的元件，是一項雲端服務，可協助您佈建身分識別及其授權給 SAP 雲端和內部部署應用程式。 |
| XSUAA | 適用於 Cloud Foundry 使用者帳戶和驗證的擴充服務。 Cloud Foundry，可以在不同基礎結構上部署的平台即服務 (PaaS)，其為 SAP 建置 SAP 商業技術平台的環境。 XSUAA 是多租用戶 OAuth 授權伺服器，其為 Cloud Foundry 環境的中央基礎結構元件。 XSUAA 提供 SAP BTP 內的商務使用者驗證和授權。 |
| Fiori | SAP 的 Web 使用者體驗 (不同於桌面體驗)。 |
概觀
SAP 和 Microsoft 技術堆疊中有許多服務與元件，在使用者驗證和授權案例中扮演著重要角色。 下圖列出主要的服務。
由於可能的案例設定排列方式非常多，因此我們將焦點放在採用 Microsoft Entra 身分識別優先策略的一種案例。 我們會進行下列假設：
- 您想要集中管理所有身分識別，而不是只透過 Microsoft Entra。
- 您想要盡可能減少維護工作，並將所有 Microsoft 與 SAP 的驗證和應用程式存取自動化。
- 搭配使用 Microsoft Entra 與 IAS 的一般指引，適用於已在 IAS 中設定且部署於 BTP 和 SAP SaaS 應用程式上的應用程式。 此外，也會提供適用於 BTP 和 SAP SaaS 應用程式的特定建議，前者如搭配使用角色對應和 Microsoft Entra 群組，後者如使用身分識別佈建服務來進行以角色為基礎的授權。
- 我們也假設 Microsoft Entra 中已佈建使用者；任何需要使用者才能運作的 SAP 系統中都已佈建使用者。 佈建方式不拘，不論是透過手動方式、從內部部署 Active Directory 到 Microsoft Entra 連線，或透過 SAP SuccessFactors 之類的 HR 系統來進行。 因此，本文件會將 SuccessFactors 視為應用程式，就像任何其他 (現有) 使用者會登入的應用程式一樣。 我們不會涵蓋將使用者從 SuccessFactors 佈建到 Microsoft Entra 的實際程序。 如需將使用者帶入 Microsoft Entra ID 以與 SAP 工作負載搭配使用的詳細資訊，請參閱規劃部署 Microsoft Entra 以使用 SAP 來源和目標應用程式進行使用者佈建以及管理 SAP 應用程式的存取。
根據這些假設，我們主要著重於下圖所示的產品及服務。 這些是與雲端式環境驗證和授權最相關的各種元件。
如果您一直使用 SAP 身分識別管理 (IDM)，則可以將身分識別管理案例從 SAP IDM 遷移至 Microsoft Entra。 如需詳細資訊，請參閱將身分識別管理案例從 SAP IDM 遷移至 Microsoft Entra。
注意
這裡的大部分指引也適用於 Azure Active Directory B2C，但有一些重要差異。 如需詳細資訊，請參閱將 Azure AD B2C 作為識別提供者。
警告
請注意 SAP SAML 判斷提示限制，以及 SAP Cloud Foundry 角色集合名稱長度和 SAP 雲端識別服務中群組代理之集合數量的影響。 如需詳細資訊，請參閱 SAP for Me 中的 SAP 備註 2732890。 超過限制會導致授權問題。
建議
摘要
- 1 - 透過 SAP 身分識別驗證服務，在 SAP 商業技術平台和 SAP SaaS 應用程式中使用同盟驗證
- 2 - 使用 Microsoft Entra ID 進行驗證，並使用 IAS/BTP 進行授權
- 3 - 透過 IAS/BTP 中的角色集合，使用 Microsoft Entra 群組進行授權
- 4 - 僅針對具有類似身分識別需求的應用程式使用單一 BTP 子帳戶
- 5 - 使用生產 IAS 租用戶進行所有終端使用者的驗證和授權
- 6 - 定義 SAML 簽署憑證的變換程序
1 - 透過 SAP 身分識別驗證服務，在 SAP 商業技術平台和 SAP SaaS 應用程式中使用同盟驗證
上下文
BTP 中的應用程式可以透過信任設定來使用識別提供者，其會利用 BTP/XSUAA 與識別提供者之間的 SAML 2.0 通訊協定來驗證使用者。 請注意，即使在應用程式本身與 BTP/XSUAA 之間使用 OpenID Connect 通訊協定 (與本內容不相關)，也只支援 SAML 2.0。
在 BTP 中，您可以選擇設定對 SAP 雲端識別服務 - Identity Authentication 的信任設定 (預設設定)，但當授權使用者目錄是 Microsoft Entra ID 時，您可以設定同盟，讓使用者可以透過自己現有的 Microsoft Entra ID 帳戶登入。
在同盟之上，您也可以選擇性地設定使用者佈建，以讓 BTP 預先佈建 Microsoft Entra ID 的使用者。 不過，此作業並無原生支援 (僅適用於 Microsoft Entra ID -> SAP 身分識別驗證服務)；BTP 身分識別佈建服務才是具有原生支援的整合式解決方案。 預先佈建使用者帳戶可能適合授權用途 (例如，將使用者新增至角色)。 不過，您也可以根據需求使用 Microsoft Entra 群組來達成此目的 (參閱以下內容)，這樣一來您可能完全不需要佈建使用者。
設定同盟關聯性時，有多個選項可供選擇：
- 您可以選擇直接從 BTP/XSUAA 建立與 Microsoft Entra 的同盟。
- 您可以選擇與 IAS 同盟，系統即會將 IAS 設定為與 Microsoft Entra 同盟作為公司識別提供者 (也稱為「SAML Proxy 處理」)。
若是 SAP SaaS 應用程式，系統會佈建並預先設定 IAS，讓終端使用者能夠輕鬆上線。 (此類應用程式範例包括 SuccessFactors、 Marketing Cloud、Cloud for Customer、Sales Cloud 及其他。)這類案例較不複雜，因為 IAS 是直接與目標應用程式連線，而不是與 XSUAA 進行 Proxy 處理。 在任何情況下，相同規則都會套用至這項設定，如同一般的 Microsoft Entra ID 與 IAS 搭配案例。
建議做法是什麼？
當授權使用者目錄是 Microsoft Entra ID 時，建議在 BTP 中設定對 IAS 的信任設定。 系統即會將 IAS 設定為與 Microsoft Entra ID 同盟作為公司識別提供者。
在 BTP 的信任設定中，建議啟用 [Create Shadow Users During Logon]。 如此一來，尚未在 BTP 中建立的使用者，即可在第一次透過 IAS/Microsoft Entra ID 登入時自動取得帳戶。 如果停用這項設定，就只會允許預先佈建的使用者登入。
為何有此建議？
使用同盟時，您可以選擇定義 BTP 子帳戶層級的信任設定。 在這種情況下，您必須針對所使用的每個其他子帳戶重複設定。 使用 IAS 作為中繼信任設定時，您可以從跨多個子帳戶的集中式設定中受益，並得以使用風險型驗證和集中式的判斷提示屬性擴充等 IAS 功能。 為了保護使用者體驗，您應該只在單一位置實施這些進階的安全性功能。 這位置可以是 IAS，或是在將 Microsoft Entra ID 維持為單一授權使用者存放區的情況下 (如同本報告的前提)，則由 Microsoft Entra ID 條件式存取管理集中處理。
注意：IAS 會將每個子帳戶都會視為「應用程式」，即使該子帳戶中可能部署了一或多個應用程式亦同。 在 IAS 中，每個這類應用程式都可以設定為相同公司識別提供者 (此案例為 Microsoft Entra ID) 的同盟。
實作摘要
在 Microsoft Entra ID 中：
- 您可以選擇性地設定 Microsoft Entra ID 無縫單一登入 (無縫 SSO)，其可在使用者使用連線到公司網路的公司裝置時，自動將其登入。 當此功能啟用時，使用者不需要輸入密碼就能登入 Microsoft Entra ID，而且在大部分情況下，甚至也不用輸入其使用者名稱。
在 Microsoft Entra ID 和 IAS 中：
- 遵循文件 (SAP 文件、Microsoft 文件) 的指示，以同盟 (Proxy) 模式連線 Microsoft Entra ID 和 IAS。 請注意 Microsoft Entra ID 中 SSO 設定的
NameID設定，因為 UPN 不一定是電子郵件地址。 - 若要將 [Bundled Application] 設定為使用 Microsoft Entra ID，請前往條件式驗證 頁面，並將 [Default Authenticating Identity Provider] 設定為代表您 Microsoft Entra ID 目錄的公司識別提供者。
在 BTP 中：
- 設定對 IAS 的信任設定 (SAP 文件)，並確認啟用 [Available for User Logon] \(可供使用者登入\) 和 [Create Shadow Users During Logon] \(在登入時建立影子使用者\)。
- 您可以選擇性地停用預設 [SAP ID Service] \(SAP 識別碼服務\) 信任設定上的 [Available for User Logon] \(可供使用者登入\)，讓使用者一律透過 Microsoft Entra ID 進行驗證，而不會在螢幕上對其顯示用以選擇識別提供者的選項。
2 - 使用 Microsoft Entra ID 進行驗證，並使用 IAS/BTP 進行授權
上下文
當 BTP 和 IAS 已設定為透過 Microsoft Entra ID 同盟進行使用者驗證時，您可以使用多個選項來設定授權：
- 在 Microsoft Entra ID 中，您可以將Microsoft Entra 使用者和群組指派給企業應用程式，代表您在 Microsoft Entra ID 中的 SAP IAS 執行個體。
- 在 IAS 中，您可以使用風險型驗證來允許或封鎖登入，以防止存取 BTP 中的應用程式。
- 在 BTP 中，您可以使用角色集合來定義哪些使用者和群組可以存取應用程式及取得特定角色。
建議做法是什麼？
建議不要將任何授權直接放在 Microsoft Entra 當中，並在 Microsoft Entra ID 中明確關閉企業應用程式上的「需要使用者指派」。 請注意，針對 SAML 應用程式，預設會啟用這項設定，因此您必須採取明確的動作加以停用。
為何有此建議？
當應用程式已透過 IAS 成為同盟時，從 Microsoft Entra ID 角度來看，使用者基本上是在登入流程期間「向 IAS 進行驗證」。 這表示 Microsoft Entra ID 沒有使用者嘗試登入的最終 BTP 應用程式資訊。 也就是說，Microsoft Entra ID 中的授權只能用來進行非常粗略的授權，例如允許使用者登入 BTP 中的「任何」應用程式，或「無」應用程式。 這也強調了 SAP 在 BTP 子帳戶層級上隔離應用程式和驗證機制的策略。
雖然這是使用 [需要使用者指派] 的有效原因，卻表示現在您可能需要維護下列兩個不同位置的授權資訊：企業應用程式上的 Microsoft Entra ID (適用於「所有」BTP 應用程式)，以及每個 BTP 子帳戶。 這可能會導致混淆和設定錯誤，因為授權設定會在其中一處更新，另一處則不會更新。 例如：若您在 BTP 中允許使用者，卻未將該使用者指派給 Microsoft Entra ID 中的應用程式，則會導致驗證失敗。
實作摘要
在代表具 IAS 同盟關聯的 Microsoft Entra 企業應用程式上，停用「需要使用者指派」。 這也表示您可以安全地略過使用者指派作業。
3 - 透過 IAS/BTP 中的角色集合，使用 Microsoft Entra 群組進行授權
上下文
當要設定 BTP 應用程式的授權時，有多個選項可供選擇：
- 您可以根據已登入的使用者，直接在應用程式內部設定更細緻的存取控制。
- 您可以根據使用者指派或群組指派，透過 BTP 中的角色和角色集合來指定存取權。
最終實作可以結合這兩種策略。 不過，若要透過角色集合進行指派，您可以逐個使用者進行，也可以使用已設定的識別提供者群組。
建議做法是什麼？
如果您想要使用 Microsoft Entra ID 作為更細緻授權的授權來源，建議使用 Microsoft Entra 群組，並將其指派給 BTP 中的角色集合。 將特定應用程式的存取權授與使用者，單純意指將這些使用者新增到相關的 Microsoft Entra 群組，而不需進一步進行 IAS/BTP 的必要設定。
使用此設定時，建議使用 Microsoft Entra 群組的群組識別碼 (物件識別碼) 作為群組的唯一識別碼，而非顯示名稱 ( "sAMAccountName")。 這表示您必須使用群組識別碼作為 Microsoft Entra ID 所簽發 SAML 權杖中的「群組」判斷提示。 此外，群組識別碼會用於 BTP 中的角色集合指派。
為何有此建議？
如果您將「使用者」直接指派給 BTP 中的角色集合，您就無法在 Microsoft Entra ID 內集中管理授權決策。 這也表示使用者必須已經存在於 IAS 中，才能將其指派給 BTP 中的角色集合；因此若按照我們建議的同盟方式，而非使用者佈建，當想要進行使用者指派時，IAS 中可能還不存在使用者的影子帳戶。 使用 Microsoft Entra 群組並將其指派給角色集合，可排除這些問題。
將群組指派給角色集合可能與先前建議不要使用 Microsoft Entra ID 來進行「授權」有點矛盾。 然而，即使在此情況下，授權決策仍在 BTP 中進行，只是說決策現在是以 Microsoft Entra ID 中所維護的群組成員資格為依據。
我們建議使用 Microsoft Entra 群組的群組識別碼，而不是其名稱，因為群組識別碼是全域唯一且不可變的，未來也不得重複使用於另一個群組；而使用群組名稱可能會在名稱變更時導致問題，而且若您刪除群組後再使用相同名稱建立另一個群組，但該群組中的使用者不應具備應用程式存取權時，即會有安全性風險。
實作摘要
在 Microsoft Entra ID 中：
- 建立群組，以將需要存取 BTP 應用程式的使用者新增至其中 (例如，為 BTP 中每個角色集合建立 Microsoft Entra 群組)。
- 在代表具 IAS 同盟關聯的 Microsoft Entra 企業應用程式上，設定 SAML 使用者屬性及宣告，以為安全性群組新增群組宣告：
將 [來源屬性] 設定為 [群組識別碼]，並將 [名稱] 設為
Groups(拼寫需完全相同，使用大寫的 'G')。此外，為了讓宣告承載保持較小的範圍，並避免發生 Microsoft Entra ID 將 SAML 判斷提示中的群組宣告數目限制為 150 的情況，強烈建議將宣告中所傳回群組設定為僅限明確指派的群組：
- 在「宣告中應傳回與使用者相關聯的哪些群組？」下，回答「指派給應用程式的群組」。然後，針對您想要包含為宣告的群組，使用 [使用者和群組] 區段將它們指派給企業應用程式，然後選取 [新增使用者/群組]。
在 IAS 中：
- 在 [識別身分同盟] 選項下的 [公司識別提供者] 設定中，確認已停用 [使用 Identity Authentication 使用者存放區]；否則，來自 Microsoft Entra ID 的群組資訊將不會保留在傳送給 BTP 的 SAML 權杖中，而會導致授權失敗。
注意
如果您「必須」使用身分識別驗證使用者存放區 (例如，若要包含無法從 Microsoft Entra ID 取得但可在 IAS 使用者存放區中使用的宣告)，您可以讓此設定保持啟用狀態。 不過，在這種情況下，您就必須設定傳送給應用程式的預設屬性，以包含來自 Microsoft Entra ID 的相關宣告 (例如使用 ${corporateIdP.Groups} 格式)。
在 BTP 中：
- 在該子帳戶中應用程式所使用的角色集合上，新增 IAS 識別提供者的設定，並將名稱設定為 Microsoft Entra 群組的群組識別碼 (物件識別碼)，以將角色集合對應至使用者群組。
注意
如果您想將用於 BTP 中的授權資訊包含在另一個 Microsoft Entra ID 宣告中，您就「不需要」使用 Groups 宣告名稱。 當將角色集合對應到上述的使用者群組時，BTP 即會使用這項資訊，但您也可以將角色集合對應到使用者屬性 (英文) 以擁有更多彈性。
4 - 僅針對具有類似身分識別需求的應用程式使用單一 BTP 子帳戶
上下文
在 BTP 中，每個子帳戶可以包含多個應用程式。 不過，從 IAS 的觀點來看，「應用程式套件組合」是一個完整的 BTP 子帳戶，而不是其中更細微的應用程式。 這表示所有信任設定、驗證和存取設定，以及 IAS 中的商標和版面配置選項，都適用於該子帳戶內的所有應用程式。 同樣地，BTP 中所有信任設定和角色集合也適用於該子帳戶內的所有應用程式。
建議做法是什麼？
建議只有在多個應用程式的身分識別層級 (使用者、群組、識別提供者、角色、信任設定、商標等等) 有類似需求時，才將多個應用程式合併在單一 BTP 子帳戶中。
為何有此建議？
如果您將身分識別需求大相徑庭的多個應用程式合併到 BTP 單一子帳戶，您最後得到的設定可能不太安全，或更容易設定錯誤。 例如：當 BTP 中單一應用程式的共用資源 (例如識別提供者) 設定有所變更時，即會影響所有依賴此共用資源的應用程式。
實作摘要
請仔細思考您要如何跨 BTP 子帳戶進行多個應用程式的分組。 如需詳細資訊，請參閱 SAP 帳戶模型文件 (英文)。
5 - 使用生產 IAS 租用戶進行所有終端使用者的驗證和授權
上下文
使用 IAS 時，您通常會有生產和開發/測試租用戶。 針對 BTP 中的不同子帳戶或應用程式，您可以選擇要使用哪一個識別提供者 (IAS 租用戶)。
建議做法是什麼？
建議一律使用生產 IAS 租用戶來與終端使用者進行任何互動，即使是在開發/測試版本環境或終端使用者必須登入的「應用程式」環境亦同。
建議僅使用其他 IAS 租用戶來測試身分識別相關的設定，因為這必須在與生產租用戶隔離的情況下完成。
為何有此建議？
因為 IAS 是一種集中式元件，且已設定與 Microsoft Entra ID 建立同盟關係，所以只能由單一位置來設定及維護同盟和身分識別設定。 如果您在其他 IAS 租用戶中複製此作業，可能會導致設定錯誤，或是終端使用者存取環境之間的不一致。
6 - 定義 SAML 簽署憑證的變換程序
上下文
在設定 Microsoft Entra ID 與 IAS 之間以及 IAS 與 BTP 之間的同盟關係時，系統會交換 SAML 中繼資料，其中包含 X.509 憑證，以用於雙方之間傳送的 SAML 權杖加密和密碼編譯簽章。 這些憑證具有到期日，而且必須定期更新 (即使在發生憑證洩漏這類緊急情況時亦同)。
注意：用來簽署 SAML 判斷提示的初始 Microsoft Entra 憑證預設有效期間為 3 年 (另請注意，憑證是專用於企業應用程式，不同於 Microsoft Entra ID 中由全域憑證所簽署的 OpenID Connect 和 OAuth 2.0 權杖)。 您可以選擇產生具有不同到期日的新憑證，或建立並匯入您自己的憑證。
憑證過期時就無法再使用，且必須設定新的憑證。 因此，系統必須建立一個程序，確保信賴憑證者 (其必須確認簽章有效) 內的憑證設定，其狀態與用來簽署 SAML 權杖的實際憑證保持一致。
在某些情況下，信賴憑證者可以透過提供中繼資料端點 (其會動態傳回最新的中繼資料資訊) 自動完成上述作業。此端點通常是可公開存取的 URL，信賴憑證者可以透過此 URL 定期擷取中繼資料，並更新其內部設定存放區。
不過，IAS 只允許透過匯入中繼資料 XML 檔案來設定公司識別提供者，而不支援提供中繼資料端點來動態擷取 Microsoft Entra 中繼資料 (例如 https://login.microsoftonline.com/my-azuread-tenant/federationmetadata/2007-06/federationmetadata.xml?appid=my-app-id)。 同樣地，BTP 也不允許透過 IAS 中繼資料端點設定新的信任設定 (例如 https://my-ias-tenant.accounts.ondemand.com/saml2/metadata)，而需要一次性上傳中繼資料 XML 檔案。
建議做法是什麼？
設定任何兩個系統 (例如 Microsoft Entra ID 與 IAS 以及 IAS 與 BTP) 之間的身分識別同盟時，請確定您已掌握所使用憑證的到期日。 請確認這些憑證可以事先取代，而且有記載的程序可在所有相依於這些憑證之信賴憑證者中更新新中繼資料。
如先前所述，建議在 BTP 中設定對 IAS 的信任設定，系統即會將 IAS 設定為與 Microsoft Entra ID 建立同盟關係，作為公司識別提供者。 在此情況下，用於 SAML 簽署和加密的下列憑證非常重要：
- BTP 中的子帳戶憑證：當此項目變更時，必須更新 IAS 中的應用程式 SAML 2.0 設定。
- IAS 中的租用戶憑證：當此項目變更時，必須更新 Microsoft Entra ID 中的企業應用程式 SAML 2.0 設定和 BTP 中的信任設定。
- Microsoft Entra ID 中的企業應用程式憑證：當此項目變更時，必須更新 IAS 中的公司識別提供者 SAML 2.0 設定。
SAP 提供實作用戶端憑證通知與 SAP Cloud 整合，及即將到期之處理的範例。 這可以調整為使用 Azure Integration Services 或 PowerAutomate。 不過，您需要將其調整為使用伺服器憑證。 這類方法需要自訂實作。
為何有此建議？
如果允許憑證過期，或在憑證被取代當下相依於這些憑證的信賴憑證者未更新新的憑證資訊，使用者就無法再透過同盟登入任何應用程式。 這可能表示當重新設定中繼資料以還原服務時，所有使用者都會經歷顯著的停機時間。
實作摘要
在 Microsoft Entra ID 中新增憑證到期的電子郵件通知位址，並將它設定為群組信箱，如此一來，系統就不會將通知傳送給單一使用者，以免在憑證即將到期時該帳戶失效。 根據預設，只有建立企業應用程式的使用者會收到通知。
請考慮建置自動化來執行整個憑證變換程序。 舉例來說，該程序可以定期檢查即將到期的憑證，並在使用新的中繼資料更新所有信賴憑證者時取代這些憑證。
將 Azure AD B2C 作為識別提供者
Azure Active Directory B2C 提供企業對客戶的身分識別即服務。 雖然說 Azure AD B2C 整合類似於讓企業使用者透過 Microsoft Entra ID 登入的方式，但當想要讓客戶、消費者或公民使用 Azure AD B2C，並允許他們使用其慣用的社交、企業或本機帳戶身分識別時，上述建議大部分仍適用。
不過，有一些重要的差異。 本部落格文章更詳細地介紹如何將 Azure AD B2C 設定為 IAS 中的企業識別提供者以及在兩個租用戶之間設定同盟。
在 Azure AD B2C 中註冊 SAML 應用程式
Azure AD B2C 沒有企業應用程式的資源庫，無法供您輕鬆地設定對 IAS 中公司識別提供者的信任關係。 因此，您將必須使用自訂原則，在 Azure AD B2C 中註冊 SAML 應用程式。 不過，此 SAML 應用程式扮演的邏輯角色與 Microsoft Entra ID 中的企業應用程式相同，因此也適用 SAML 憑證變換的相同指引。
Azure AD B2C 的授權
Azure AD B2C 原本就不支援使用群組來建立可指派存取權的使用者集合，這表示您必須以不同方式來實作透過 BTP 中的角色集合來使用 Microsoft Entra 群組進行授權指引。
幸運的是，Azure AD B2C 具有極大的自訂空間，因此您可以將要傳送給 IAS 的 SAML 權杖設定為包含任何自訂資訊。 如需支援授權宣告的各種選項，請參閱 Azure AD B2C 應用程式角色範例 (英文) 中隨附的文件；總結來說：透過其 API 連接器擴充性機制，您可以選擇性地使用群組、應用程式角色，甚至是自訂資料庫，以判斷允許使用者存取哪些內容。
無論授權資訊來自何處，您都可以將 Groups 屬性名稱設為宣告結構描述上的預設合作夥伴宣告類型，或覆寫輸出宣告上的合作夥伴宣告類型，以將這些資訊視為 SAML 權杖內的屬性來發出。 不過，請注意，BTP 可讓您將角色集合對應至使用者屬性 (英文)，這表示即使您未使用 Groups 屬性名稱，也可以使用「任何」屬性名稱進行授權決策。