案例 - 使用 Microsoft Entra 識別符來保護對 SAP 平臺和應用程式的存取

  • 發行項

本檔提供使用 Microsoft Entra ID 做為主要使用者驗證服務時，SAP 平臺和應用程式的技術設計和設定建議。 在本教學課程中深入瞭解初始設定。

本指南使用的詞彙

縮寫 描述
BTP SAP Business Technology Platform。 整個 SAP 的技術供應專案。 這裏討論的大部分 SAP 技術都是 BTP 的一部分。 正式稱為 SAP 雲端平台的產品是 SAP BTP 的一部分。
Ias SAP 雲端身分識別服務 - 身分識別驗證服務。 SAP 所提供的多租用戶雲端識別提供者服務。 IAS 可協助使用者向自己的 SAP 服務實例進行驗證。
Id SAP ID 服務。 SAP 用來向 SAP 營運的 PaaS 和 SaaS 服務驗證客戶和合作夥伴的 IAS 實例。
Ip SAP 雲端身分識別服務 - 身分識別布建服務。 IPS 有助於同步處理不同存放區/目標系統之間的身分識別。
XSUAA Cloud Foundry 用戶帳戶和驗證的擴充服務。 XSUAA 是 SAP BTP 內的多租使用者 OAuth 授權伺服器。
Cf Cloud Foundry。 Cloud Foundry 是 SAP 為其為 BTP 建置其多重雲端供應項目的環境（AWS、Azure、GCP、Alibaba）。
Fiori SAP 的網頁式用戶體驗（而不是桌面型體驗）。

概觀

SAP 和 Microsoft 技術堆疊中有許多服務和元件，在使用者驗證和授權案例中扮演角色。 下圖列出主要服務。

SAP landscape overview

由於可能設定的案例有許多排列，因此我們會將焦點放在一個符合 Microsoft Entra 身分識別優先策略的案例上。 我們將進行下列假設：

  • 您想要集中控管所有身分識別，且只從 Microsoft Entra ID 管理。
  • 您想要盡可能減少維護工作，並將 Microsoft 和 SAP 之間的驗證和應用程式存取自動化。
  • 搭配 IAS 的 Microsoft Entra 識別碼一般指導方針適用於在 IAS 中設定的 BTP 和 SAP SaaS 應用程式上部署的應用程式。 在適用於 BTP 的情況下，也會提供特定建議（例如，搭配 Microsoft Entra 群組使用角色對應）和 SAP SaaS 應用程式（例如，針對角色型授權使用身分識別布建服務）。
  • 我們也假設使用者已在 Microsoft Entra ID 中布建，並針對需要布建使用者才能運作的任何 SAP 系統。 無論達到何種目的：布建都可以透過手動方式、從 內部部署的 Active Directory 到 Microsoft Entra 連線，或透過 SAP SuccessFactors 等 HR 系統。 因此，在本檔中，SuccessFactors 會被視為應用程式，就像任何其他使用者將登入的應用程式一樣。 我們不會涵蓋將使用者從 SuccessFactors 實際布建到 Microsoft Entra ID。

根據這些假設，我們主要著重於下圖中顯示的產品和服務。 這些元件與雲端式環境中的驗證和授權最相關。

SAP services in scope

注意

這裡的 大部分指引也適用於 Azure Active Directory B2C ，但有一些重要的差異。 如需詳細資訊，請參閱 使用 Azure AD B2C 作為識別提供者 。

警告

請注意 SAP SAML 判斷提示限制，以及 SAP Cloud Foundry 角色集合名稱和 SAP Cloud Identity Service 中群組所代理的集合數量長度和影響。 如需詳細資訊，請參閱 SAP 附注 2732890 。 超過限制會導致授權問題。

建議

摘要

1 - 透過 SAP 身分識別驗證服務，在 SAP Business Technology Platform 和 SAP SaaS 應用程式中使用同盟驗證

上下文

BTP 中的應用程式可以透過 信任組態 使用識別提供者，透過 BTP/XSUAA 與識別提供者之間的 SAML 2.0 通訊協定來驗證使用者。 請注意，即使應用程式本身與 BTP/XSUAA 之間使用 OpenID 連線 通訊協定，也僅支援 SAML 2.0（在此內容中並不相關）。

在 BTP 中，您可以選擇為 SAP ID Service 設定信任設定（這是預設值），但當您的授權使用者目錄是 Microsoft Entra ID 時，您可以設定 同盟 ，讓使用者可以使用其現有的 Microsoft Entra 帳戶登入。

在同盟之上，您也可以選擇性地設定 使用者布 建，讓 Microsoft Entra 用戶預先布建在 BTP 中。 不過，沒有原生支援此專案（僅適用於 Microsoft Entra ID -> SAP Identity Authentication Service）：具有原生支援的整合式解決方案會是 BTP 身分識別布建服務。 預先布建用戶帳戶對於授權用途很有用（例如，將使用者新增至角色）。 不過，視需求而定，您也可以使用 Microsoft Entra 群組來達成此目的，這可能表示您完全不需要使用者布建。

設定同盟關聯性時，有多個選項：

  • 您可以選擇直接從 BTP/XSUAA 同盟至 Microsoft Entra ID。
  • 您可以選擇與 IAS 同盟，然後設定為將 Microsoft Entra ID 同盟為公司識別提供者（也稱為「SAML Proxying」）。

針對 SAP SaaS 應用程式 IAS，會佈建並預先設定，以便輕鬆上線使用者。 （例如 SuccessFactors、Marketing Cloud、Cloud4Customer、Sales Cloud 等。此案例較不複雜，因為 IAS 會與目標應用程式直接連線，而不是 Proxy 到 XSUAA。 在任何情況下，此設定會套用與 IAS 一般 Microsoft Entra 識別符相同的規則。

我們建議什麼？

當您的授權使用者目錄是 Microsoft Entra ID 時，建議您在 BTP 中設定 IAS 的信任設定。 IAS 接著會設定為與 Microsoft Entra ID 建立同盟，作為公司識別提供者。

SAP trust configuration

在 BTP 中的信任設定上，建議啟用「登入期間建立陰影使用者」。 如此一來，尚未在 BTP 中建立的使用者，第一次透過 IAS / Microsoft Entra ID 登入時，會自動取得帳戶。 如果停用此設定，則只允許預先布建的使用者登入。

為何建議？

使用同盟時，您可以選擇在 BTP 子帳戶層級定義信任設定。 在此情況下，您必須針對所使用的其他 Subaccount 重複設定。 藉由使用 IAS 作為中繼信任組態，您可以從多個子帳戶的集中式設定中獲益，而且您可以使用 IAS 功能，例如風險型驗證和判斷提示屬性的集中式擴充。 為了保護使用者體驗，這些進階安全性功能應該只在單一位置強制執行。 這可能是 IAS，或將 Microsoft Entra ID 保留為單一授權使用者存放區時（如同本文的前提），Microsoft Entra 條件式存取管理會集中處理。

注意：對 IAS，即使在該子帳戶內可以部署一或多個應用程式，每個 Subaccount 都會被視為「應用程式」。 在 IAS 中，每個這類應用程式都可以設定為與相同的公司識別提供者同盟（在此案例中為 Microsoft Entra ID）。

實作摘要

在 Microsoft Entra 標識符中：

  • 選擇性地 將 Microsoft Entra ID 設定為無縫單一登錄 （無縫 SSO），當使用者在連線到公司網路的公司裝置上時，會自動將使用者登入。 當此功能啟用時，使用者不需要輸入密碼就能登入 Microsoft Entra ID，而且在大部分情況下，甚至也不用輸入其使用者名稱。

在 Microsoft Entra ID 和 IAS 中：

在 BTP 中：

  • 設定對 IAS（SAP 檔）的信任設定，並確保同時啟用「可供使用者登入」和「在登入期間建立陰影使用者」。
  • 或者，在預設的「SAP ID 服務」信任設定上停用「可供使用者登入」，讓使用者一律透過 Microsoft Entra ID 進行驗證，而且不會顯示畫面來選擇其識別提供者。

2 - 使用 Microsoft Entra ID 進行驗證，並使用 IAS/BTP 進行授權

上下文

當 BTP 和 IAS 已透過同盟設定為透過 Microsoft Entra ID 進行使用者 驗證 時，有多個選項可用來設定 授權：

  • 在 Microsoft Entra ID 中，您可以將 Microsoft Entra 使用者和群組指派給企業應用程式，代表 Microsoft Entra 標識碼中的 SAP IAS 實例。
  • 在 IAS 中，您可以使用風險型驗證來允許或封鎖登入，並執行該動作來防止在 BTP 中存取應用程式。
  • 在 BTP 中，您可以使用角色集合來定義哪些使用者和群組可以存取應用程式並取得特定角色。

我們建議什麼？

我們建議您不要直接將任何授權放在 Microsoft Entra 本身，並明確地關閉 Microsoft Entra 識別符中的企業應用程式上的「需要使用者指派」。 請注意，針對 SAML 應用程式，預設會啟用此設定，因此您必須採取明確的動作來停用它。

為何建議？

透過 IAS 同盟應用程式時，從 Microsoft Entra ID 的觀點來看，使用者基本上會在登入流程期間「向 IAS 進行驗證」。 這表示 Microsoft Entra ID 沒有使用者嘗試登入的最終 BTP 應用程式相關信息。 這也表示 Microsoft Entra ID 中的授權只能用來執行非常粗略的授權，例如允許使用者登入 BTP 中的任何應用程式，或無。 這也強調 SAP 在 BTP 子帳戶層級隔離應用程式和驗證機制的策略。

雖然這可能是使用「需要使用者指派」的有效原因，但它確實表示現在可能有兩個不同的位置需要維護授權資訊：兩者都是在企業應用程式上的 Microsoft Entra ID 中（適用於 所有 BTP 應用程式的位置），以及每個 BTP 子帳戶中。 這可能會導致混淆和設定錯誤，其中授權設定會在某個位置更新，但不會更新另一個位置。 例如：BTP 中允許使用者，但未指派給 Microsoft Entra 識別碼中的應用程式，導致驗證失敗。

實作摘要

在代表與 IAS 同盟關係的 Microsoft Entra Enterprise 應用程式上，停用 [需要使用者指派]。 這也表示您可以安全地略過 使用者指派。

3 - 在 IAS/BTP 中透過角色集合使用 Microsoft Entra 群組進行授權

上下文

當您要設定 BTP 應用程式的授權時，有多個選項：

  • 您可以根據登入的使用者，在應用程式本身內設定更細緻的訪問控制。
  • 您可以根據使用者指派或群組指派，透過 BTP 中的角色和角色集合來指定存取權。

最終實作可以使用這兩種策略的組合。 不過，若要透過角色集合進行指派，這可以依使用者逐一完成，或者一個可以使用已設定識別提供者的群組。

我們建議什麼？

如果您想要使用 Microsoft Entra 識別碼作為授權來源以進行更細緻的授權，建議您使用 Microsoft Entra 群組，並將其指派給 BTP 中的角色集合。 將特定應用程式的存取權授與使用者，只需將它們新增至相關的 Microsoft Entra 群組，而不需要在 IAS/BTP 中進行任何進一步的設定。

使用此設定時，建議使用 Microsoft Entra 群組的群組標識碼 （物件識別元） 作為群組的唯一標識符，而不是顯示名稱 （“sAMAccountName” ）。 這表示您必須使用群組標識碼做為 Microsoft Entra ID 所簽發之 SAML 令牌中的「群組」判斷提示。 此外，群組標識碼用於將指派給 BTP 中的角色集合。

Using Role Collections in SAP

為何建議？

如果您將使用者直接指派給 BTP 中的角色集合，則不會集中處理 Microsoft Entra ID 中的授權決策。 這也表示用戶必須已存在於 IAS 中，才能指派給 BTP 中的角色集合，而且由於我們建議同盟，而不是使用者布建，這表示在您想要執行使用者指派時，使用者影子帳戶可能還不存在於 IAS 中。 使用 Microsoft Entra 群組並將其指派給角色集合可排除這些問題。

將群組指派給角色集合似乎與先前的建議相矛盾，不要使用 Microsoft Entra ID 進行 授權。 不過，即使在此案例中，授權決策仍在 BTP 中執行，只是此決定現在是以 Microsoft Entra ID 中維護的群組成員資格為基礎。

建議您使用 Microsoft Entra 群組的群組識別碼，而不是其名稱，因為群組標識碼是全域唯一的、不可變的，且稍後再無法重複使用給另一個群組：而使用組名可能會導致名稱變更時發生問題，而且刪除群組時有安全性風險，而另一個群組則以相同名稱建立，但其中的使用者應該無法存取應用程式。

實作摘要

在 Microsoft Entra 標識符中：

  • 建立需要 BTP 中應用程式存取權的使用者可以新增的群組（例如，在 BTP 中為每個角色集合建立 Microsoft Entra 群組）。
  • 在代表與 IAS 同盟關係的 Microsoft Entra Enterprise 應用程式上，設定 SAML 使用者屬性和宣告，以 新增安全組的群組宣告：

    • 將 Source 屬性設定為 「Group ID」，並將 Name 設定為 Groups （拼字完全相同，大小寫為 『G』）。

    • 此外，為了保持宣告承載很小，並避免發生限制，Microsoft Entra ID 會將 SAML 判斷提示中的群組宣告數目限制為 150，強烈建議您將宣告中傳回的群組限制為僅將明確指派的群組：

      • 在 [宣告中應傳回哪些與使用者相關聯的群組？] 底下，回答「指派給應用程式的群組」。 然後，針對您想要包含為宣告的群組，使用 [使用者和群組] 區段將它們指派給企業應用程式，然後選取 [新增使用者/群組]。

      Microsoft Entra group Claim configuration

在 IAS 中：

  • 在 [公司識別提供者] 設定的 [身分識別同盟] 選項底下，確定您停用 [使用身分識別驗證使用者存放區];否則，來自 Microsoft Entra ID 的群組資訊將不會保留在 SAML 令牌中的 BTP，授權將會失敗。

注意

如果您需要使用身分識別驗證使用者存放區（例如，若要包含無法從 Microsoft Entra ID 來源但可在 IAS 使用者存放區中取得的宣告），您可以保持啟用此設定。 不過，在此情況下，您必須設定 傳送至應用程式 的默認屬性，以包含來自 Microsoft Entra ID 的相關宣告（例如 ${corporateIdP.Groups} 格式）。

在 BTP 中：

注意

如果 Microsoft Entra ID 中有另一個宣告，以包含 BTP 中要使用的授權資訊，則不需要使用Groups宣告名稱。 當您將角色集合對應至上述使用者群組時，BTP 會使用此功能，但您也可以 將角色集合對應至用戶屬性 ，這可讓您更有彈性。

4 - 僅針對具有類似身分識別需求的應用程式使用單一 BTP 子帳戶

上下文

在 BTP 內，每個子帳戶可以包含多個應用程式。 不過，從 IAS 的觀點來看，「配套應用程式」是完整的 BTP 子帳戶，而不是更細微的應用程式。 這表示 IAS 中的所有信任設定、驗證和存取設定，以及 IAS 中的商標和版面配置選項都會套用至該子帳戶內的所有應用程式。 同樣地，BTP 中的所有信任設定和角色集合也適用於該 Subaccount 內的所有應用程式。

我們建議什麼？

我們建議您只有在身分識別層級上有類似的需求時，才能在單一 BTP 子帳戶中結合多個應用程式（使用者、群組、身分識別提供者、角色、信任設定、品牌、...）。

為何建議？

藉由將具有非常不同身分識別需求的多個應用程式合併到 BTP 中的單一子帳戶，您最終可能會有不安全的設定，或更容易設定錯誤。 例如：當設定變更為像身分識別提供者這樣的共享資源時，BTP 中的單一應用程式，這會影響依賴此共用資源的所有應用程式。

實作摘要

請仔細考慮如何在 BTP 中跨子帳戶將多個應用程式分組。 如需詳細資訊，請參閱 SAP 帳戶模型檔。

5 - 針對所有使用者驗證和授權使用生產 IAS 租使用者

上下文

使用 IAS 時，您通常會有生產環境與開發/測試租使用者。 針對 BTP 中的不同子帳戶或應用程式，您可以選擇要使用的識別提供者（IAS 租使用者）。

我們建議什麼？

我們建議一律使用生產 IAS 租使用者來與用戶進行任何互動，即使在開發/測試版本或應用程式環境的內容中，他們都必須登入。

我們建議只使用其他 IAS 租用戶來測試身分識別相關設定，這必須與生產租用戶隔離。

為何建議？

由於 IAS 是已設定為與 Microsoft Entra 識別子同盟的集中式元件，因此只有單一位置必須設定和維護同盟和身分識別設定。 在其他 IAS 租使用者中複製這項設定可能會導致環境在使用者存取時設定錯誤或不一致。

6 - 定義 SAML 簽署憑證變換的程式

上下文

設定 Microsoft Entra ID 與 IAS 之間的同盟，以及 IAS 與 BTP 之間的同盟時，會交換 SAML 元數據，其中包含用於在雙方之間傳送之 SAML 令牌加密和密碼編譯簽章的 X.509 憑證。 這些憑證具有到期日，而且必須定期更新（即使在憑證遭到入侵的緊急情況下，例如）。

注意：用來簽署 SAML 判斷提示的初始 Microsoft Entra 憑證的預設有效期間為 3 年（請注意，憑證是企業應用程式特有的，不同於 OpenID 連線 和 OAuth 2.0 令牌，這些令牌是由 Microsoft Entra ID 中的全局憑證所簽署）。 您可以選擇 使用不同的到期日產生新的憑證，或建立並匯入您自己的憑證。

當憑證到期時，就無法再使用憑證，而且必須設定新的憑證。 因此，必須建立程式，以將憑證設定保留在信賴憑證者內部（需要驗證簽章），以使用實際憑證簽署 SAML 令牌。

在某些情況下，信賴憑證者可以透過動態傳回最新元數據資訊的元數據端點來自動執行這項操作，也就是信賴憑證者可以定期擷取元數據並更新其內部組態存放區的可公開存取 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 的信任設定，然後設定為將 Microsoft Entra ID 同盟為公司識別提供者。 在此情況下，下列憑證（用於 SAML 簽署和加密）很重要：

  • BTP 中的子帳戶憑證：當此變更時，必須更新 IAS 中的應用程式 SAML 2.0 組態。
  • IAS 中的租用戶憑證：當這項變更時，必須更新企業應用程式的SAML 2.0 設定 Microsoft Entra ID 和 BTP 中的信任設定。
  • Microsoft Entra 識別碼中的企業應用程式憑證：當此變更時，必須在 IAS 中更新公司識別提供者的 SAML 2.0 設定。

Rolling over SAML Signing Certs

SAP 具有使用 SAP 雲端整合和即將到期處理之用戶端憑證通知的範例實作。 這可與 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 樣。

後續步驟