方案 - 使用 Microsoft Entra ID 来保护对 SAP 平台和应用程序的访问

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

本指南中使用的术语

概述

SAP 中有许多服务和组件，Microsoft技术堆栈在用户身份验证和授权方案中发挥作用。 下图中列出了主要服务。

由于可能配置的方案有很多排列，因此我们专注于一个与 Microsoft Entra 标识优先策略一致的方案。 我们将做出以下假设：

• 你希望集中管理所有标识，并且仅从 Microsoft Entra ID 进行管理。
• 你希望尽可能减少维护工作，并跨 Microsoft 和 SAP 自动执行身份验证和应用访问。
• 有关使用 IAS 的 Microsoft Entra ID 的一般指南适用于在 IAS 中配置的 BTP 和 SAP SaaS 应用上部署的应用。 此外，还将提供适用于 BTP（例如，将角色映射与 Microsoft Entra 组配合使用）和 SAP SaaS 应用（例如，使用基于角色的授权的标识预配服务）。
• 我们还假设用户已在 Microsoft Entra ID 中预配，并针对任何需要预配用户才能正常运行的 SAP 系统。 无论如何实现此目的：预配都可以通过手动方式、从本地 Active Directory 到 Microsoft Entra Connect，或通过 SAP SuccessFactors 等 HR 系统。 因此，在本文档中，SuccessFactors 被视为像任何其他用户登录的应用程序一样。 我们不会介绍从 SuccessFactors 到 Microsoft Entra ID 中用户的实际预配。 若要详细了解如何将用户引入 Microsoft Entra ID 以用于 SAP 工作负载，请参阅 计划部署 Microsoft Entra，以便通过 SAP 源和目标应用程序进行用户预配 ，以及 管理对 SAP 应用程序的访问权限。

根据这些假设，我们主要关注下图中显示的产品和服务。 这些组件与基于云的环境中的身份验证和授权最相关。

如果一直在使用 SAP 标识管理 （IDM），则可以将标识管理方案从 SAP IDM 迁移到 Microsoft Entra。 有关详细信息，请参阅 将标识管理方案从 SAP IDM 迁移到 Microsoft Entra。

Recommendations

概要

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

1 - 通过 SAP 标识身份验证服务在 SAP Business Technology Platform 和 SAP SaaS 应用程序中使用联合身份验证

上下文

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

在 BTP 中，可以选择设置对 SAP Cloud Identity Services - Identity Authentication（默认值）的信任配置，但当权威用户目录Microsoft Entra ID 时，可以设置 联合 身份验证，以便用户可以使用其现有Microsoft Entra 帐户登录。

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

设置联合关系时，有多个选项：

• 可以选择直接从 BTP/XSUAA 联合Microsoft Entra ID。
• 可以选择与 IAS 联合，而 IAS 又设置为将 Microsoft Entra ID 联合为企业标识提供者（也称为“SAML 代理”）。

为 SAP SaaS 应用程序 IAS 预配和预配置，以便轻松载入最终用户。 （例如 SuccessFactors、Marketing Cloud、Cloud for Customer、Sales Cloud 等。此方案不太复杂，因为 IAS 与目标应用直接连接，而不是代理到 XSUAA。 在任何情况下，此设置适用的规则与使用 IAS 的 Microsoft Entra ID 相同。

我们建议什么？

当权威用户目录Microsoft Entra ID 时，我们建议在 BTP 中针对 IAS 设置信任配置。 IAS 反过来设置为与 Microsoft Entra ID 作为企业标识提供者进行联合。

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

为什么此建议？

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

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

实现摘要

在Microsoft Entra ID 中：

• （可选） 为无缝单一登录（无缝 SSO）配置 Microsoft Entra ID ，以便在用户连接到企业网络的公司设备上自动登录。 启用后，用户无需键入密码即可登录到 Microsoft Entra ID，通常甚至键入其用户名。

在Microsoft Entra ID 和 IAS 中：

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

在 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 ID 表示 SAP IAS 实例。
• 在 IAS 中，可以使用基于风险的身份验证来允许或阻止登录，并这样做可防止在 BTP 中访问应用程序。
• 在 BTP 中，可以使用角色集合来定义哪些用户和组可以访问应用程序并获取特定角色。

我们建议什么？

建议不要将任何授权直接放入 Microsoft Entra 本身，并在 Enterprise Application 上显式关闭Microsoft Entra ID 中的“用户分配必需”。 请注意，对于 SAML 应用程序，此设置默认处于启用状态，因此必须采取显式作才能禁用它。

为什么此建议？

通过 IAS 联合应用程序时，从 Microsoft Entra ID 的角度来看，用户在登录流中实质上是“向 IAS 进行身份验证”。 这意味着，Microsoft Entra ID 没有有关用户尝试登录的最终 BTP 应用程序的信息。 这也意味着，Microsoft Entra ID 中的授权只能用于执行非常粗粒度的授权，例如允许用户登录到 BTP 中的任何 应用程序，或者 不登录任何应用程序。 这还强调了 SAP 在 BTP 子帐户级别隔离应用和身份验证机制的策略。

虽然这可能是使用“需要用户分配”的有效原因，但它确实意味着现在可能有两个不同的位置需要维护授权信息：无论是在企业应用程序（适用于 所有 BTP 应用程序的位置）还是在每个 BTP 子帐户中Microsoft Entra ID 中。 这可能会导致混淆和配置错误，其中授权设置在一个位置更新，而不是另一个位置。 例如：BTP 中允许用户，但在Microsoft Entra ID 中未分配给应用程序，从而导致身份验证失败。

实现摘要

在表示与 IAS 的联合关系的 Microsoft Entra Enterprise 应用程序上，禁用“需要用户分配”。 这也意味着可以安全地跳过用户分配。

3 - 在 IAS/BTP 中通过角色集合使用 Microsoft Entra 组进行授权

上下文

如果要为 BTP 应用程序配置授权，有多种选项：

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

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

我们建议什么？

如果要使用 Microsoft Entra ID 作为细化授权的权威源，建议使用 Microsoft Entra 组并将其分配到 BTP 中的角色集合。 授予用户对某些应用程序的访问权限，只需将它们添加到相关的Microsoft Entra 组（s），而无需在 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 Enterprise 应用程序上，配置 SAML 用户属性和 声明以添加安全组的组声明：

  • 将 Source 属性设置为“组 ID”，并将 Name 设置为 Groups （拼写完全类似于此，大写为“G”）。

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

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

    

在 IAS 中：

• 在企业标识提供者配置中，在“联合身份验证”选项下，确保禁用“使用标识身份验证用户存储”;否则，不会在 SAML 令牌中保留来自 Microsoft Entra ID 的组信息，并且授权会失败。

在 BTP 中：

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

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 年（请注意，该证书特定于企业应用程序，不同于 OpenID Connect 和 OAuth 2.0 令牌，这些令牌由 Microsoft Entra ID 中的全局证书签名）。 可以选择 生成具有不同到期日期的新证书，或创建并导入自己的证书。

证书过期后，不能再使用这些证书，并且必须配置新证书。 因此，必须建立一个过程，以在信赖方（需要验证签名）中保留证书配置，以便使用用于对 SAML 令牌进行签名的实际证书。

在某些情况下，信赖方可以通过向信赖方提供动态返回最新元数据信息的元数据终结点（即，信赖方可以定期检索元数据并更新其内部配置存储）来自动执行此作。

但是，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 ID 中的企业应用程序证书：更改时，必须更新企业标识提供者在 IAS 中的 SAML 2.0 配置。

SAP 具有使用 SAP Cloud Integration 和即将过期处理的客户端证书通知的示例实现。 这可以改编为 Azure Integration Services 或 Power Automate。 但是，需要对其进行调整才能使用服务器证书。 此方法需要自定义实现。

为什么此建议？

如果允许证书过期或及时替换证书，但依赖证书的信赖方不会使用新的证书信息进行更新，则用户将无法再通过联合身份验证登录到任何应用程序。 这可能导致所有用户在还原服务时通过重新配置元数据来显著停机。

实现摘要

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

请考虑生成自动化以执行整个证书滚动更新过程。 例如，可以定期检查过期的证书，并在使用新元数据更新所有信赖方时替换它们。

后续步骤

• 详细了解本教程中的初始设置
• 规划使用 SAP 源和目标应用程序和目标应用程序部署 Microsoft Entra 进行用户预配
• 管理对 SAP 应用程序的访问权限
• 使用 Microsoft Entra ID 及更高版本发现其他 SAP 集成方案