场景 - 使用 Microsoft Entra ID 保护对 SAP 平台和应用程序的访问

本文档提供在使用 Microsoft Entra ID 作为 SAP 云标识服务的主要用户身份验证服务时，有关 SAP 平台和应用程序技术设计和配置的建议。 SAP 云标识服务包括 Identity Authentication、标识预配、标识目录和授权管理。 详细了解 Microsoft Entra 单一登录 (SSO) 与 SAP 云标识服务集成教程中用于身份验证的初始设置。 有关预配和其他方案的详细信息，请参阅规划部署 Microsoft Entra 以通过 SAP 源和目标应用程序进行用户预配，以及管理对 SAP 应用程序的访问。

本指南中使用的术语

缩写	说明
BTP	SAP 业务技术平台是针对云中的 SAP 应用程序进行了优化的创新平台。 此处讨论的大多数 SAP 技术都属于 BTP。 正式名称为 SAP Cloud Platform 的产品是 SAP BTP 的一部分。
IAS	SAP 云标识服务 - Identity Authentication 是 SAP 云标识服务的组件，是用于在 SAP 云和本地应用程序中进行身份验证、单一登录和用户管理的云服务。 作为集成了 Microsoft Entra 单一登录的代理，IAS 可帮助用户向自己的 SAP BTP 服务实例进行身份验证。
IPS	SAP 云标识服务 - Identity Authentication 是 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 ID 进行管理。
• 你希望尽可能减少维护工作，并跨 Microsoft 和 SAP 自动进行身份验证和应用访问。
• 针对使用 IAS 的 Microsoft Entra ID 的一般指南适用于部署在 BTP 上的应用和在 IAS 中配置的 SAP SaaS 应用。 如果适用于 BTP（例如，将角色映射用于 Microsoft Entra 组）和 SAP SaaS 应用（例如，使用标识预配服务进行基于角色的授权），我们还将提供具体建议。
• 我们还假设用户已在 Microsoft Entra ID 中进行预配，并面向需要预配用户才能正常运行的任何 SAP 系统。 无论实现方式如何，都可以通过 Microsoft Entra Connect 或 HR 系统（例如 SAP SuccessFactors）从本地 Active Directory 手动进行预配。 因此，在本文档中，SuccessFactors 被视为与（现有）用户将要登录的任何其他应用程序类似的应用程序。 我们不介绍用户从 SuccessFactors 到 Microsoft Entra ID 的实际预配。 有关将用户引入 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 Cloud Identity Service 中的组代理的集合数量的影响。 有关详细信息，请参阅 SAP for Me 中的 SAP 说明 2732890。 超出限制会导致授权问题。

建议

总结

• 1 - 通过 SAP Identity Authentication 服务在 SAP 业务技术平台和 SAP SaaS 应用程序中使用联合身份验证
• 2 - 使用 Microsoft Entra ID 进行身份验证，使用 IAS/BTP 进行授权
• 3 - 使用 Microsoft Entra 组通过 IAS/BTP 中的角色集合进行授权
• 4 - 仅对具有类似标识要求的应用程序使用单个 BTP 子帐户
• 5 - 将生产 IAS 租户用于所有最终用户的身份验证和授权
• 6 - 定义 SAML 签名证书的轮换过程

1 - 通过 SAP Identity Authentication 服务在 SAP 业务技术平台和 SAP SaaS 应用程序中使用联合身份验证

上下文

BTP 中的应用程序可以通过信任配置使用标识提供者，借助 BTP/XSUAA 和标识提供者之间的 SAML 2.0 协议对用户进行身份验证。 请注意，仅支持 SAML 2.0，即便在应用程序本身和 BTP/XSUAA 之间使用了 OpenID Connect 协议（在此上下文中无关紧要）。

在 BTP 中，可以选择设置针对 SAP 云标识服务 - Identity Authentication（这是默认值）的信任配置，但如果授权用户目录是 Microsoft Entra ID，则可以设置“联合身份验证”，以便用户使用其现有的 Microsoft Entra 帐户进行登录。

除了联合身份验证之外，也可选择设置“用户预配”，以便在 BTP 中预先预配 Microsoft Entra 用户。 但是，对此没有原生支持（仅适用于 Microsoft Entra ID -> SAP Identity Authentication 服务）；具有原生支持的集成解决方案是 BTP 标识预配服务。 对于授权，预先预配用户帐户（例如，将用户添加到角色）可能很有用。 但是，根据需求不同，也可使用 Microsoft Entra 组来实现此目的（见下文），这可能意味着你根本不需要用户预配。

建立联合身份验证关系时，有多种选项可供选择：

• 可以选择直接从 BTP/XSUAA 与 Microsoft Entra ID 建立联合身份验证。
• 可以选择与 IAS 建立联合身份验证，进而将其设置为与作为公司标识提供者的 Microsoft Entra ID 建立联合身份验证（也称为“SAML 代理”）。

对于 SAP SaaS 应用程序，我们预配并预先配置了 IAS，以便最终用户可以轻松加入。 （此示例包括 SuccessFactors、营销云、Cloud for Customer、销售云等。）这种情况不太复杂，因为 IAS 与目标应用直接连接，而不是通过代理连接到 XSUAA。 在任何情况下，与使用 IAS 的 Microsoft Entra ID 相同的规则通常都适用于此设置。

我们建议你做什么？

如果授权用户目录是 Microsoft Entra ID，我们建议在 BTP 中针对 IAS 设置信任配置。 相应地，将 IAS 设置为与作为公司标识提供者的 Microsoft Entra ID 建立联合身份验证。

在 BTP 中的信任配置上，建议启用“在登录期间创建影子用户”。 这样，尚未在 BTP 中创建的用户在首次通过 IAS/Microsoft Entra ID 登录时将自动获得一个帐户。 如果禁用此设置，则仅允许预先预配的用户登录。

为什么要选择此建议？

当使用联合身份验证时，可以选择在 BTP 子帐户级别定义信任配置。 在这种情况下，必须为所使用的每个其他子帐户重复配置。 通过使用 IAS 作为中间信任配置，你可以从跨多个子帐户的集中式配置中获益，并且可以使用 IAS 功能，例如基于风险的身份验证和断言属性的集中扩充。 为保护用户体验，这些高级安全功能应仅在一个位置强制实施。 这可以是 IAS，也可以是将 Microsoft Entra ID 作为单一授权用户存储（这是本文的前提条件），这将由 Microsoft Entra 条件访问管理集中处理。

注意：对于 IAS，每个子帐户都被视为一个“应用程序”，即使在该子帐户中可以部署一个或多个应用程序。 在 IAS 中，每个此类应用程序都可以设置为与同一公司标识提供者（在本例中为 Microsoft Entra ID）建立联合身份验证。

实现总结

在 Microsoft Entra ID 中：

• （可选）配置 Microsoft Entra ID 以实现无缝单一登录（无缝 SSO），可使连接到公司网络的公司设备上的用户自动登录。 启用此功能后，用户无需键入其密码即可登录到 Microsoft Entra ID；通常情况下，甚至无需键入其用户名。

在 Microsoft Entra ID 和 IAS 中：

• 按照文档操作，在联合身份验证（代理）模式下将 Microsoft Entra ID 连接到 IAS（SAP 文档、Microsoft 文档）。 请注意 Microsoft Entra ID 中 SSO 配置的 NameID 设置，因为 UPN 不一定是电子邮件地址。
• 通过转至“条件身份验证”页面并将“默认身份验证标识提供者”设置为表示 Microsoft Entra ID 目录的公司标识提供者，可以将“捆绑的应用程序”配置为使用 Microsoft Entra ID。

在 BTP 中：

• 设置针对 IAS 的信任配置（SAP 文档），并确保“可供用户登录”和“在登录期间创建影子用户”均已启用。
• （可选）在默认的“SAP ID 服务”信任配置中禁用“可供用户登录”，以便用户始终通过 Microsoft Entra ID 进行身份验证，并且不会出现用于选择用户标识提供者的屏幕。

2 - 使用 Microsoft Entra ID 进行身份验证，使用 IAS/BTP 进行授权

上下文

当通过面向 Microsoft Entra ID 的联合身份验证为用户身份验证配置了 BTP 和 IAS 后，有多种用于配置授权的选项可供选择：

• 在 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 - 使用 Microsoft Entra 组通过 IAS/BTP 中的角色集合进行授权

上下文

为 BTP 应用程序配置授权时，有多种选项可供选择：

• 可以根据登录用户在应用程序中配置更详细的访问控制。
• 可以根据用户分配或组分配，通过 BTP 中的角色和角色集合指定访问权限。

最终实现可结合使用这两种策略。 但是，对于通过角色集合进行的分配，可以针对不同的用户分别完成此操作，也可使用配置了标识提供者的组。

我们建议你做什么？

如果要使用 Microsoft Entra ID 作为精细授权的授权源，建议使用 Microsoft Entra 组并将其分配给 BTP 中的角色集合。 授予用户对某些应用程序的访问权限意味着只需将其添加到相关的 Microsoft Entra 组，而无需在 IAS/BTP 中进行任何进一步配置。

通过此配置，建议使用 Microsoft Entra 组的组 ID（对象 ID）作为组的唯一标识符，而不是显示名称（“sAMAccountName”）。 这意味着必须使用组 ID 作为 Microsoft Entra ID 颁发的 SAML 令牌中的“组”断言。 此外，组 ID 用于分配给 BTP 中的角色集合。

为什么要选择此建议？

如果将用户直接分配给 BTP 中的角色集合，则不会在 Microsoft Entra ID 中集中授权决策。 这也意味着 IAS 中必须已经存在用户，然后才能将其分配给 BTP 中的角色集合，鉴于我们建议使用联合身份验证而非用户预配，这意味着在要进行用户分配时，IAS 中可能尚不存在用户的影子帐户。 通过使用 Microsoft Entra 组并将其分配给角色集合，可解决这些问题。

将组分配给角色集合似乎与之前的建议（即不使用 Microsoft Entra ID 进行授权）自相矛盾。 然而，即使在这种情况下，授权决定仍在 BTP 中进行，只不过决定现在基于 Microsoft Entra ID 中维护的组成员身份。

建议使用 Microsoft Entra 组的组 ID 而不是组名称，因为组 ID 是全局唯一的且不可变，并且以后永远不会被其他组重复使用，而使用组名可能会导致在名称更改时出现问题，并且在以下情况下存在安全风险：删除了某个组，然后使用相同的名称创建了另一个组，但该组中的用户应无法访问应用程序。

实现总结

在 Microsoft Entra ID 中：

• 创建一个可向其添加需要访问 BTP 中应用程序的用户的组（例如，为 BTP 中的每个角色集合创建一个 Microsoft Entra 组）。
• 在表示与 IAS 建立联合身份验证关系的 Microsoft Entra 企业应用程序上，配置 SAML 用户属性和声明以为安全组添加组声明：

  • 将“源属性”设置为“组 ID”并将“名称”设置为 Groups（照此拼写，请大写“G”）。

  • 此外，为了使声明有效负载较小并避免遇到 Microsoft Entra ID 将 SAML 声明中的组声明数量限制为 150 的限制，我们强烈建议将声明中返回的组限制为仅那些显式分配的组：

    • 在“应在声明中返回与用户关联的哪些组？”下，答案为“分配给应用程序的组”。然后，对于要作为声明包括的组，请使用“用户和组”部分并选择“添加用户/组”将其分配到企业应用程序。

    

在 IAS 中：

• 在“公司标识提供者”配置中的“联合身份验证”选项下，确保禁用“使用 Identity Authentication 用户存储”；否则，Microsoft Entra ID 中的组信息将不会保留在面向 BTP 的 SAML 令牌中，并且授权将失败。

注意

如果需要使用 Identity Authentication 用户存储（例如，包含无法从 Microsoft Entra 溯源的，但已在 IAS 用户存储中提供的声明），则可以保持启用此设置。 但在这种情况下，需要配置发送到应用程序的默认属性，以包含来自 Microsoft Entra ID 的相关声明（例如使用 ${corporateIdP.Groups} 格式）。

在 BTP 中：

• 在该子帐户中的应用程序使用的“角色集合”上，通过为 IAS 标识提供者添加配置并将“名称”设置为 Microsoft Entra 组的“组 ID(对象 ID)”，将角色集合映射到用户组。

注意

如果使用 Microsoft Entra ID 中的另一个声明来包含要在 BTP 中使用的授权信息，则不必使用 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 元数据，其中包含用于对双方之间发送的 SAML 令牌进行加密和加密签名的 X.509 证书。 这些证书具有到期日期，必须定期更新（即使在证书被泄露的紧急情况下）。

注意：用于对 SAML 断言进行签名的初始 Microsoft Entra 证书的默认有效期为 3 年（请注意，该证书特定于企业应用程序，与由 Microsoft Entra ID 中的全局证书签名的 OpenID Connect 和 OAuth 2.0 令牌不同）。 可以选择生成具有不同到期日期的新证书，也可创建并导入自己的证书。

证书过期后不能再使用，必须配置新的证书。 因此，必须建立一个流程，以使信赖方内部的证书配置（需要验证签名）与用于对 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 中的租户证书：当该证书更改时，必须同时更新 Microsoft Entra ID 中企业应用程序的 SAML 2.0 配置和 BTP 中的信任配置。
• Microsoft Entra ID 中的企业应用程序证书：当该证书更改时，必须更新 IAS 中公司标识提供者的 SAML 2.0 配置。

SAP 提供了 SAP Cloud Integration 和即将到期处理的客户端证书通知的示例实现。 这可以通过 Azure Integration Services 或 PowerAutomate 进行调整。 但是，它们需要经过调整才能使用服务器证书。 此类方法需要自定义实现。

为什么要选择此建议？

如果允许证书过期，或者及时替换了证书但依赖这些证书的信赖方没有使用新的证书信息进行更新，用户将无法再通过联合身份验证登录任何应用程序。 这可能意味着，当通过重新配置元数据来还原服务时，所有用户的停机时间很长。

实现总结

在 Microsoft Entra ID 中添加证书到期的电子邮件通知地址，并将其设置为组邮箱，这样就不会将其发送给单个用户（证书即将到期时，此用户可能不再拥有帐户）。 默认情况下，只有创建了企业应用程序的用户才会收到通知。

考虑使用生成自动化来执行整个证书轮换过程。 例如，可以定期检查到期证书并替换这些证书，同时使用新的元数据更新所有信赖方。

使用 Azure AD B2C 作为标识提供者

Azure Active Directory B2C 以服务的形式提供企业到客户的标识。 鉴于与 Azure AD B2C 的集成类似于允许企业用户在 Microsoft Entra ID 中登录的方式，当你想要为客户、消费者或居民使用 Azure AD B2C 并允许他们使用首选的社交、企业或本地帐户标识时，上述大部分建议仍然适用。

不过存在一些重要的差别。 本博客文章更详细地介绍了在 IAS 中将 Azure AD B2C 设置为企业标识提供者以及在两个租户之间配置联合身份验证。

在 Azure AD B2C 中注册 SAML 应用程序

Azure AD B2C 不提供企业应用程序库用于轻松配置与 IAS 中企业标识提供者的信任关系。 必须改用自定义策略在 Azure AD B2C 中注册 SAML 应用程序。 但是，此 SAML 应用程序与 Microsoft Entra ID 中的企业应用程序扮演相同的逻辑角色，因此 SAML 证书滚动更新等方面的指导同样适用。

Azure AD B2C 授权

Azure AD B2C 并不原生支持使用组来创建可向其分配访问权限的用户集合，这意味着，必须以不同的方式实施有关使用 Microsoft Entra 组通过 BTP 中的角色集合进行授权的指导。

幸运的是，Azure AD B2C 高度可自定义，因此你可以配置它发送到 IAS 的 SAML 令牌，以包含任何自定义信息。 有关支持授权声明的各种选项，请参阅 Azure AD B2C 应用角色示例随附的文档，但总而言之：通过其 API 连接器扩展机制，仍可以选择性地使用组、应用角色甚至自定义数据库，来确定允许用户访问的内容。

无论授权信息来自何处，随后都可以将它作为 SAML 令牌中的 Groups 属性发出，方法是将该属性名称配置为声明架构上的默认合作伙伴声明类型，或者替代输出声明上的合作伙伴声明类型。 但请注意，BTP 允许将角色集合映射到用户属性，这意味着，任何 属性名称都可用于授权决策，即使你不使用 Groups 属性名称。

后续步骤

• 在本教程中详细了解初始设置
• 规划部署 Microsoft Entra 以通过 SAP 源和目标应用程序进行用户预配和
• 管理对 SAP 应用程序的访问
• 了解其他与 Microsoft Entra ID 的 SAP 集成方案及更多内容