UAA 概念

参考 UAA Concepts 。

本主题说明用户帐户和身份认证（UAA）的核心概念。

1. 概述

UAA 体系结构有六个主要组件：

• 身份区域
• 子域名
• 用户
• 用户组
• 客户端
• 选择范围和权限

2. 身份区域

UAA 旨在支持多租户架构。每个租户都称为一个身份区域。

身份区域是 UAA 管理的实体周围的逻辑边界。区域中的实体包括但不限于：

• Client registrations：客户端注册
• Users：用户
• Groups：组
• Group mappings：组映射
• User approvals：用户许可
• Identity providers (IDPs) and access：身份认证提供者和访问
• ID and refresh tokens：身份和刷新令牌

具有两个标识区域等效于建立两个独立的 UAA 部署，但使用的资源较少。这种类型的资源管理可以减少运营和维护开销。

3. 子域名

身份区域由 UAA 中的子域标识符唯一标识。如果 UAA 部署托管在 URL https://login.EXAMPLE-CF-DOMAIN.com 上，则身份区域将托管为同一部署的子域。

例如:

• zone1: https://ZONE1.login.EXAMPLE-CF-DOMAIN.com
• zone2: https://ZONE2.login.EXAMPLE-CF-DOMAIN.com

3.1. 默认区域

UAA 部署始终具有一个称为 默认区域 的区域。您可以使用 YAML 配置文件配置和引导默认区域。

4. 用户

用户 是 UAA 服务器的中央域对象。由于 UAA 既充当帐户存储又充当授权服务器，因此许多不同类型的信息都链接到用户，并且可以通过以用户为中心的 API 调用进行访问。

UAA 作为用户帐户存储，可以提供描述单个用户的独特属性，例如电子邮件，姓名，电话号码和组成员身份。除了这些属性外，UAA 还跟踪一些动态用户元数据，例如上次成功登录时间和上次更新时间。

如果将 UAA 配置为使用来自外部 IDP（例如现有 LDAP 或 SAML 提供程序）的自定义属性映射，则可以使其他属性可用。有关 IDP 选项的详细信息，请参阅UAA 中的 身份提供程序。

外部 IDP 和这些提供程序的属性都是只读的。对外部用户帐户的任何更改都应直接在外部 IDP 上执行。每次用户通过外部 IDP 进行身份验证时，都会刷新这些只读属性。

UAA 可用作授权服务器，它允许客户端应用程序使用四个标准的 OAuth2 授权授予流来代表用户与资源进行交互，以获取访问令牌：

• Authorization code：授权码
• Implicit：隐含式（授权码隐含式）
• Resource owner password credentials：资源所有者密码凭据
• Client credentials：客户端凭据

UAA 用户是 OAuth2 协议的资源所有者。颁发给用户的访问令牌包含范围位于请求客户端允许的范围和用户的组成员资格的交集。

4.1. user.id

user.id 是用于在 API 中标识用户的字符串。此通用唯一标识符是在用户创建时随机生成的，并且不会更改。它保证在 UAA 部署中的所有标识区域中都是唯一的。user.id 是一个 128 位数字，格式为 UUID。这也表示为 UAA 生成的令牌中的 “sub” 声明。

4.2. user.origin

UAA 中的用户始终属于用户存储库，别名为 origin。例如，通过 UAA 本身使用用户名和密码进行身份验证的用户的来源设置为 uaa。

固定的 origin 值为：

• uaa：经 UAA 部署认证的用户
• ldap：经 LDAP 提供程序认证的用户
• {OIDC provider alias}：经 OIDC provider 认证的用户
• {SAML provider alias}：经 SAML IDP 认证的用户

经过外部 IDP 身份验证的用户在 UAA 中通常称为影子用户。有关更多信息，请参见 影子用户。

4.3. user.userName

user.userName 是指向用户的用户可读字符串，通常是电子邮件地址。用户通过 UAA 进行身份验证时输入其用户名。

如果用户通过外部 IDP 进行身份验证，则用户名将从该 IDP 转移到 UAA 中的影子用户。可以通过用户名和原始值的组合来唯一标识单个用户。

单独的用户名不是唯一的值。由于用户名可以更改，因此 UAA 提供用户 ID 作为对单个用户的不变引用。有关更多信息，请参见 user.id。

通过 UAA UI 创建帐户的用户将其电子邮件地址用作用户名。管理 API 可以创建指定任意用户名的用户帐户。

对于外部 IDP，用户名是从 UAA 收到的断言中映射的。

• SAML： UAA 从 nameID 声明中检索用户名。例如：

<saml2:NameID> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
SAML-USERNAME
</saml2:NameID>

其中 SAML-USERNAME 是 UAA 检索到的用户名。 * LDAP： UAA 从用户输入中获取用户名。 * OIDC1.0 / OAuth2： UAA 从 OpenID Connect 和 OAuth2 提供程序的 id_token、用户信息端点或访问令牌中获取用户名。用户名以 JSON Web 令牌（JWT）格式返回。可以配置保存用户名值的声明的名称，默认为 preferred_username。

5. 用户组

用户可以属于一个或多个组。组是表达通用的基于组或基于角色的访问控制模型的一种方式。组具有显示名称。该名称是一个任意字符串，直接与 JWT 访问令牌中的范围相对应，并用于 OAuth2 资源服务器的访问控制。

常见的组属性是：

• type： 这可以是两种成员资格类型之一，即 DIRECT 和 INDIRECT。DIRECT 表示用户直接与该组关联。INDIRECT 表示成员资格是从组的嵌套成员资格继承的。
• display：用户所属组的名称。displayName 是给定标识区域唯一的标识符，并且表示授予用户的访问权限。

5.1. 默认用户组

您可以将 UAA 配置为具有一个或多个默认组。这些是系统中每个用户都属于的组，即使用户与数据库中的组之间没有直接关系也是如此。

5.2. 影子用户

通过外部 IDP 进行身份验证的用户仍会在 UAA 数据库的 users 表中分配一条记录。这些用户通常称为影子用户。

UAA 内部用户的 user.origin 为 uaa。影子用户与内部用户有所区别，内部用户的来源与外部 IDP 不同。每次外部用户通过身份验证并将断言传递给 UAA 时，UAA 都会刷新用户信息。这意味着直到 UAA 上一次收到带有用户信息的断言之前，有关 UAA 中影子用户的信息都是准确的。 影子用户具有不同类型的组成员身份。影子用户可以通过其来源与组关联。每次接收到新的断言时，此成员身份也可能更改。

影子用户还可以使用 group_membership.origin='uaa' 来定义组成员身份。这些成员身份保持不变，并且在断言报告外部组成员身份发生更改时不会更改。它还允许 UAA 操作员为外部提供商不知道或无法映射到外部组的用户分配特权。

6. 客户端

UAA 是 OAuth2 授权服务器。在应用程序获取访问令牌之前，开发人员必须执行一次性注册过程才能在 UAA 中创建客户端。

客户端通常代表具有自己的一组权限和配置的应用程序。客户端受简单的凭据（例如客户端 ID 和机密）保护，应用程序使用这些凭据对 UAA 进行身份验证以获得令牌。

客户有两种类型：

• 客户端访问资源并向 UAA 请求令牌以执行此操作
• 代表资源并接受和验证访问令牌的客户端

通过客户端注册在 UAA 中创建客户端。您可以使用 UAA 配置文件在 UAA 中定义客户端，也可以使用 UAA API 创建客户端。

6.1. 选择授权授予类型

要创建客户端，开发人员必须指定使用其客户端应允许的授权类型。授予类型决定了您的客户如何与 UAA 进行交互。每种授权类型都对应于 OAuth2 2.0 授权框架中定义的四种不同的授权流之一。有关更多信息，请参阅 OAuth2 2.0 授权框架的 授权代码 部分。

UAA 上可用的授权类型包括：

• authorization_code：授权码
• password：密码
• implicit：隐含式
• client_credentials：客户端凭据

为了提高安全性，请仅使用您的应用所需的授权类型。但是，如有必要，您可以将多种授权类型分配给一个客户端。

6.2. 选择客户授权类型

为了帮助您为用例选择授权类型，请参见下表：

6.3. client.client_id

客户端被标识为最多 255 个字符的值，称为 client_id。与 user.id 不同，client_id 通常是人类可读的标识符。例如，应用程序的名称可以是其 client_id 。该标识符在身份区域内是唯一的。

6.4. client.secret

客户端身份验证通过称为 client_secret 的密码机制进行。

UAA 允许以两种不同的方式声明客户端凭据：

• 具有使用基本身份验证的HTTP授权标头。
• 通过使用内容类型 application/x-www-form-urlencoded 将 client_id 和 client_secret 作为请求参数传递到 HTTP POST 主体中。

有关更多信息，请参阅 OAuth 2.0 授权框架的 客户端密码 部分。

6.5. client.redirect-uri

authorization_code 和隐式授予类型依赖于用户代理。诸如 Web 浏览器之类的用户代理负责执行到 UAA 的 HTTP 重定向并接收来自 UAA 的响应。该响应可以是访问令牌的形式，也可以是以后交换访问令牌的代码的形式。

支持这两个流程之一的客户端在客户端配置中必须至少具有一个 URL。另外，您可以使用多个 URL 和通配符（*）进行 ant 路径匹配。有关更多信息，请参见 Spring Framework 文档的 Class AntPathMatcher 部分。

6.6. client.access-token-validity

UAA 会在访问令牌到期之前验证访问令牌。如果客户端可以脱机验证令牌，则客户端也可以这样做。访问令牌有效性是从创建令牌到令牌到期的秒数。

6.7. client.refresh-token-validity

UAA 会验证刷新令牌，直到这些令牌过期为止。如果客户端可以脱机验证令牌，则客户端也可以这样做。刷新令牌有效性是从创建令牌到令牌到期的秒数。

7. 选择范围和权限

在构造访问令牌时，客户端范围用于填充范围声明，其中客户端代表用户进行操作。

创建访问令牌后，UAA 将获取用户组并将其与客户端范围相交。这两个字段的交集是可以在访问令牌中填充的合并范围。在确定交叉点之后，还有两种验证可以进一步限制在访问令牌中填充的范围：

1. 用户是否批准了这些范围？
2. 客户是否在授权请求中请求了这些范围？

令牌包含的作用域永远不能超过客户端作用域和用户组之间的交集。

7.1. client.autoapprove

访问令牌中的范围必须由授予实体批准。

在 client_credentials 授予期间，客户端本身就是授予实体，并自动假定客户端权限已被批准。

在授予密码期间，用户与客户端应用共享他们的密码。客户端应用假定此共享是对客户端要在访问令牌中填充的范围的隐式批准。

两种授权类型，authorization_code 和 implicit 类型需要特定的用户批准才能将范围填充到访问令牌中。 UAA 提供了一个 UI，可让用户批准或拒绝将作用域填充到访问令牌中。

在客户注册期间，操作员可以通过将自动批准的值设置为单个字符串并将其值设置为 true，来配置客户绕过此批准过程。这将导致任何请求的范围自动获得批准。

该值也可以是不需要用户批准的所选范围的逗号分隔列表。

7.2. client.additional_information

客户端可以将自定义属性存储在名为 Additional_information 的字段中。这是一个简单的键值存储。下表描述了这些自定义属性：