说明用户与身份提供者
学习目标
在 SAP BTP 上定义用户
描述 SAP BTP 上的身份提供者
SAP BTP 上的用户类型
SAP Business Technology Platform（SAP BTP）区分平台用户与业务用户：
平台用户
平台用户通常是管理员、开发人员或运维人员。管理员管理账户、权益、SaaS 应用程序、服务和环境。开发人员和运维人员在 SAP BTP 上部署、管理并排查应用程序和服务的问题。平台用户使用平台管理工具，例如 SAP BTP 驾驶舱、btp CLI 以及特定于环境的工具。子账户管理员也管理业务用户，除非这是通过 SAP Cloud Identity 服务集中完成的。账户或环境的所有平台用户通常也被称为该账户／环境的“成员”。这既包括管理员／管理者，也包括权限更受限的用户（例如开发人员或审计人员）。
业务用户
业务用户是 SAP BTP 上 SaaS 应用程序和自定义应用程序的最终用户。他们不使用平台管理工具，也不需要访问账户和环境。业务用户由子账户管理员或所连接的 SAP Cloud Identity 服务租户的管理员管理。
BTP 区分这两种用户类型，以便按用户类型启用不同的身份验证设置。例如，由于其拥有强大的权限，平台用户通常需要强身份验证（例如双因素身份验证）。当作为业务用户工作时（例如使用应用程序或服务的传统最终用户），通常较弱的身份验证就足够了。
尽管存在这种逻辑上的区分，BTP 仍尽可能对用户管理使用相同的概念。要管理全局账户、目录和子账户中的平台用户（“子账户成员”），您处理的实体和工具大多与在子账户中管理业务用户时相同。
小心
平台用户与业务用户的分离存在一些例外。典型情况是 ABAP 环境，它不区分这两种类型，以及 SAP Build Code 或 SAP Build Apps，开发人员目前是以业务用户身份访问它们的。
SAP BTP 上的用户管理
SAP BTP 上的用户与权限管理发生在所有层级，从您的全局账户，经由目录和子账户，直到您的环境。任何想要使用 SAP BTP 的人都必须在特定账户或环境中被分配相应的权限。权限分配始终特定于单个全局账户、目录、子账户或环境。不存在“完全访问”权限，例如全局账户管理员自动被授权访问所有包含的子账户，或子账户管理员自动在包含的环境中被授权。
当客户签署 SAP BTP 合同时，合同中指定的一名用户会在全局账户层级被添加为第一位全局账户管理员。同样，当您注册试用账户时，您会被设置为试用 SAP BTP 全局账户的初始管理员。全局账户管理员可以登录 SAP BTP 管理工具，并对该账户拥有完全控制权。例如，全局账户管理员可以管理权益，如全局账户的实体和服务分配，以及创建目录和子账户。为确保不止一个人能够管理全局账户，全局账户管理员还会创建更多管理员用户，并为其分配完全或受限的管理员权限。
一个全局账户由多个子账户组成，例如用于分隔不同的层级，或分隔不同组织单位的工作。子账户或目录的创建者会自动成为其初始管理员，并可根据需要添加具有不同权限的更多成员。在紧急情况下，全局账户管理员可以将自己添加为子账户和目录的管理员。
同样的模式也适用于环境。当子账户管理员创建环境时，该用户会成为（或应当成为）此环境的初始管理员，并可以向更多用户授予访问权限。
注意
创建 Kyma 或 ABAP 环境时，您需要明确指定谁应当是初始管理员，通常就是您自己。
要管理所有账户层级的成员，您通常首先使用 SAP BTP 驾驶舱。还有其他选项，例如 CLI、Terraform 提供程序，以及与 SAP Cloud Identity 服务和企业身份与访问管理（IAM）解决方案的集成。Cloud Foundry 环境的用户与权限管理非常紧密地集成在 SAP BTP 驾驶舱中，并与 SAP Cloud Identity 服务集成。对于其他环境，它与 SAP BTP 驾驶舱相对解耦，您需要在 Kyma 仪表盘或作为 ABAP 环境管理启动板的 Web Access 中维护它们。
所有环境都提供更多层级的用户与权限管理，以便更好地组织和分隔工作。尽管从概念角度我们把管理员和开发人员这类技术角色称为平台用户，但您在整个平台中找不到这个术语，尤其是在 SAP BTP 的各环境中找不到。Cloud Foundry 环境使用特定的 Cloud Foundry 角色，以及作为相应层级（组织或空间）成员的用户。Kyma 环境同样如此，它通过 Kubernetes RBAC 系统和所谓的集群角色向平台用户授予访问权限。ABAP 环境对此有所打破，在那里您对技术角色以及环境内所部署应用程序的真正最终用户都使用所谓的业务用户。
身份提供者
要登录 SAP BTP，您需要一个具有有效凭证的用户账户。原始用户账户及其凭证并不在 SAP BTP 中管理，而是在外部身份提供者中管理。SAP BTP 的大多数区域使用用户配置文件的副本，其中包含姓名和电子邮件地址等基本信息，通常称为“影子用户”。这主要用于向用户分配权限。当用户登录 BTP 工具和应用程序时，SAP BTP 会将身份验证委托给身份提供者，由后者验证用户身份，并且通常还提供有关该用户的某些信息。
默认情况下，所有 SAP BTP 账户和环境都信任 SAP ID 服务，它是 SAP 为客户运营的默认身份提供者，用于访问 SAP for Me 等工具。SAP 强烈建议改用 SAP Cloud Identity 服务的自定义租户，以便您完全控制用户账户的生命周期和所有安全设置。例如，您可以根据来自 HR 系统的事件自动禁用用户账户：使用 SAP Cloud Identity 服务的自定义租户即可做到这一点。使用 SAP ID 服务则无法做到，因为您在那里无法控制所有用户账户。
注意
中国区域使用不同的默认身份提供者。有关更多信息，请参阅此博客文章：Activate TOTP Two-Factor Authentication for Platform Users of SAP BTP in Alibaba Cloud regions.
SAP ID 服务
SAP ID 服务是默认身份提供者。与 SAP ID 服务的信任关系是默认配置的，因此不需要任何进一步配置。此服务完全由 SAP 管理。用户随后使用其 SAP ID 服务用户凭证登录 SAP BTP 工具和应用程序。如果用户没有 SAP 用户账户，必须先在 SAP ID 服务中创建。客户通常通过使用 SAP for Me 创建“S 用户”账户来完成。或者，用户可以自行注册到 SAP ID 服务。
来自 SAP ID 服务的用户通过其电子邮件地址而非用户 ID 来识别。如果您有多个共享同一电子邮件地址的用户账户，它们都会获得相同的权限。在向来自 SAP ID 服务的用户分配权限时，您只能将它们分配给单个用户。使用自定义身份提供者时，您还可以将某些权限分配给用户组。SAP ID 服务不能用于某些较新应用程序的业务用户，这些应用程序需要 SAP Cloud Identity 服务的自定义租户。例如 SAP Build Work Zone、SAP Build Apps。
提示
尤其是在生产使用时，请使用 SAP Cloud Identity 服务的自定义租户。您可以在原型设计场景中或用于测试时使用 SAP ID 服务。
SAP Cloud Identity Services – Identity Authentication
SAP 强烈建议您使用 SAP Cloud Identity Services 的自定义租户，而不是 SAP ID 服务。对于平台用户和业务用户，这都是可行且推荐的。您既可以管理自己的用户群，也可以连接您的企业身份提供者，例如 Microsoft Entra ID。有关更多详细信息，请参阅Initial Setup of SAP Cloud Identity Services。
要在 BTP 中使用 SAP Cloud Identity 服务作为身份提供者，您需要有一个自定义租户。如果您还没有，可以在 SAP BTP 驾驶舱中使用自助服务创建租户。在试用账户中也可以这样做。
注意
如果您的公司已有租户，而您不是其管理员，您通常需要让现有租户管理员参与。在某些情况下，您仍然可以建立信任，但需要租户管理员进一步配置信任，例如将用户身份验证委托给企业身份提供者或自定义登录页面。
在大多数情况下，您可以同时使用 SAP ID 服务和自定义身份提供者。这允许逐步过渡到自定义身份提供者：您可以在不把自己锁在外面的情况下建立信任，然后授权来自自定义身份提供者的用户，使用该身份提供者登录，最后从默认身份提供者中移除剩余用户。
SAP BTP 针对不同用途使用与 SAP Cloud Identity Services 分离的信任配置，例如业务用户与平台用户之间，以及（对于业务用户）不同子账户之间。即使为多个用途使用同一租户，这也使您能够为不同情况配置不同的设置，例如为生产启用多因素身份验证，而为开发和测试不启用。
平台用户的集中信任
您在全局账户层级建立此信任。
该信任适用于全局账户中的所有账户层级，直至每个子账户。它也适用于这些子账户中的所有 Cloud Foundry 环境。
当多个全局账户信任同一租户时，该信任在所有全局账户之间共享。这意味着，当您使用该租户访问 BTP 管理工具时，您可以访问您的所有 BTP 账户，因此 SAP Cloud Identity 服务中的相同安全设置适用于所有这些账户。
Kyma 环境中平台用户的独立信任
该信任适用于单个 Kyma 系统，因此实际上是子账户特定的。
Kyma 仅支持一个单一身份提供者，因此在建立到自定义身份提供者的信任时，会立即替换默认信任配置。请确保在建立信任之前至少授权一个来自自定义身份提供者的用户，或者事后使用稍后描述的紧急流程对其进行授权。
业务用户的独立信任
该信任适用于单个子账户中的业务用户。
较新的应用程序直接使用 SAP Cloud Identity 服务，而不是 SAP BTP 传统的授权与信任管理服务，它们在 SAP Cloud Identity 服务中显示为独立的信任配置，允许进行更细粒度的配置。尽管如此，来自某个子账户的所有应用程序始终信任该子账户所信任的租户。
每个子账户只建立一个自定义信任，指向 SAP Cloud Identity 服务的自定义租户，并使用 OpenID Connect 协议（OIDC）。这对所有应用程序都有效。SAP 强烈不建议在子账户中使用额外的信任配置，因为它们无法与较新的应用程序配合工作。
影子用户的概念
当管理员在某个上下文中（例如在某个子账户中）向用户授予权限时，大多数情况下这要求该上下文中存在一个基本用户配置文件，然后权限被分配到该配置文件。通常，这个称为“影子用户”的用户配置文件会在管理员分配权限时自动创建。
注意
自动创建影子用户的功能对于自定义身份提供者默认开启。作为默认身份提供者的 SAP ID 服务则禁用了该功能，因为您不会希望所有 SAP S 或 P 用户都可能存在于您的 SAP BTP 账户中。
如果您希望自动创建影子用户，例如在使用自助注册流程时，您可以为相应的身份提供者保持启用影子用户的自动创建。这意味着当用户存在于身份提供者中且允许创建影子用户时，一旦该用户登录 SAP BTP 驾驶舱或相应的 SAP BTP 应用程序或服务，就会创建该用户的副本。
然而，如果您希望控制用户可以登录哪些应用程序，您可以为某个身份提供者关闭影子用户的自动创建。这确保只有管理员手动创建的那些影子用户才能够登录。无论影子用户是手动还是自动创建的，只要该用户存在，您就可以为该用户分配角色集合。
请注意，影子用户无法再被自动删除，因为 SAP BTP 无法知道某个用户只是暂时休假一段时间后会回来，还是已永久离开公司／职位。
小心
为遵守 GDPR 法规，您需要在不再需要时删除用户的个人数据。SAP 建议您要么设置自动化流程，根据可靠信息（例如 HR 系统中的变更）删除它们，要么定期审查现有影子用户并删除不再需要的那些。
注意
影子用户通常按信任配置存在。例如，子账户成员通常也以业务用户身份使用该子账户的应用程序，因此会有两个影子用户：一个关联到业务用户的信任配置，另一个关联到平台用户的信任配置。
本课其余配图
