技术简报：Workspace 身份
用户的主工作空间身份授权访问所有工作空间资源源，包括移动应用程序、虚拟应用程序和虚拟桌面。Citrix Workspace 为组织提供了选择用户的主身份提供程序的选择。
身份提供程序 (IdP)
身份提供商是用户身份的最终权威。身份提供商负责保护和保护用户身份的策略，其中包括密码策略、多因素身份验证策略和锁定策略。
在云时代之前，组织只有身份提供商的单一选项：Windows Active Directory。但是现在，几乎每个需要唯一用户帐户的系统或服务都像身份提供商一样行事。Facebook、LinkedIn、Twitter、Workday 和 Google 都是身份提供商，因为每个人都是其服务中用户身份的最终权威。此外，常见的安全建议很少得到遵循，是为每个身份使用不同的密码来限制被盗密码的影响。
传统的身份识别方法提供了可以想象的最差的用户体验之一。用户不断面临身份验证的挑战。用户不得不记住每项服务的唯一、复杂的密码。由于忘记了凭据，用户花费了宝贵的时间来重置密码和解锁帐户。
Citrix Workspace 为现状提供了更好的替代方案。Citrix Workspace 允许每个组织从目前包括的越来越多的选项中选择主身份。
- Windows Active Directory
- Azure Active Directory
- Okta
- Citrix Gateway
- SAML 2.0
Citrix Workspace 依赖身份代理微服务来管理对配置的身份提供程序的身份验证。成功的工作区身份验证允许资源馈送 µ-service 创建用户可用的授权资源列表。
但是，由于这些服务使用不同的身份提供商，其中许多服务都具有或需要不同于用户主工作空间身份的身份。单点登录 µ-service 使用以下适当的方法将用户的主工作空间身份转换为资源特定的身份：
- SAML
- Kerberos
- 表单
- 虚拟智能卡
Citrix Workspace 的主身份和辅助身份方法创建了用户一次物理身份验证，然后自动满足所有后续身份验证挑战的体验。
身份代理
身份提供商和相关的身份数据库是用户身份的最终权威。但是，每个身份提供商都不同。每个身份提供商都包含不同的参数、策略和用户身份标准。
在 Citrix Workspace 中，身份代理 µ-service 会将主身份验证请求重定向到配置的身份提供程序。将身份验证请求传输到身份提供程序后，身份提供程序内的身份验证策略决定了用户必须如何进行身份验证，其中通常包括多因素身份验证策略。
身份提供商成功对用户进行身份验证后，身份代理 µ-service 将收到成功的身份验证响应。此方法的好处是，组织可以在身份提供程序中更改身份验证策略，而不会影响 Citrix Workspace。
除了来自身份提供商的成功身份验证响应外，身份代理 µ-service 还接收来自身份提供商的唯一信息并将其转换为关于用户的标准声明集。
关于用户的声明只是识别用户的信息，可以是 UPN、SID、GUID、电子邮件或身份提供商数据库中包含的任何其他内容。这些声明允许 Citrix Workspace 生成用户有权访问的资源和服务的列表。例如，如果用户的主要身份是 Google ID，Citrix Workspace 将使用 Google ID 来控制对未链接到 Google ID 的其他资源和服务的授权，例如 Workday、SAP、Windows、Slack 等。换句话说，借助 Citrix Workspace，用户可以使用单个 Google ID 登录到包括 Windows 在内的每个授权资源。
在 Citrix Workspace 中，身份代理 µ-service 将继续扩展，以包括适用于主身份提供商的其他选项。身份代理 µ-service 包括身份提供商，这些提供商可以从本地位置获得，或者身份代理 µ-service 可以利用基于云的身份提供商。下图概述了 Citrix Workspace 身份平台和所有当前身份提供程序选项，稍后将对这些选项进行更详细的讨论。
每个身份提供商都是唯一的；但最终，每个身份提供商都告诉 Citrix Workspace 一些关于用户的事情：
- 用户名
- 用户成功通过身份验证
- 关于用户的声明
要更好地了解每个身份提供商的详细信息，请查看以下关于主要身份提供商的
- Active Directory
- 使用 TOTP 的 Active Directory
- Azure Active Directory
- Citrix Gateway
- Okta
Active Directory
配置后，用户可以使用 Active Directory 凭据向 Citrix Workspace 进行身份验证。
要将 Citrix Workspace 与本地 Active Directory 域集成，Workspace 必须能够与域控制器进行通信。通过在本地环境中部署一组高度可用的Cloud Connector，Cloud Connector 可以使用组织的 Citrix Cloud 订阅建立出站控制通道。出站控制通道允许 Citrix Workspace 通过端口 443 安全地使用本地组件进行通信隧道，而无需修改入站防火墙端口。
Cloud Connector 包括允许 Citrix Workspace 从 Active Directory 域读取用户和组信息的 AD 提供程序服务。当用户通过 Citrix Workspace 进行身份验证时，凭据将通过 Cloud Connector 的 AD 提供程序服务发送到本地域控制器。
使用 TOTP 的 Active Directory
对于许多组织来说，使用用户名和密码提供对应用程序和桌面服务的访问不足以提供足够的安全性。Citrix Workspace 整合了云交付的 基于时间的一次性密码 (TOTP)，通过引入“您拥有的东西”（即 TOTP 令牌）和“您知道的东西”（即密码）来提供多因素身份验证。
TOTP 生成一个随机的 6 位数代码，该代码每 30 秒更改一次。此代码基于用户的移动应用程序和后端基础体系结构之间共享的密钥。密钥是多因素身份验证的“您拥有的东西”因素。为了生成随机代码，一种行业标准的安全哈希算法将应用于密钥和当前时间。为了进行身份验证，将移动应用程序中的代码与后端基础体系结构中的代码进行比较。
要注册 TOTP 服务，每个用户都会在移动设备上的身份验证器应用程序中创建并安装预共享密钥。
用户成功注册到 TOTP 微服务后，用户必须使用令牌及其 Active Directory 凭据才能成功向 Citrix Workspace 进行身份验证。
由于 TOTP 作为一项功能集成在 Citrix Workspace 中，因此在本地环境中设置和维护 TOTP 类型解决方案的复杂性已消除。借助 Citrix Workspace 中的此功能，管理员可以启用该服务，用户注册设备。
启用基于 TOTP 的多因素身份验证时，有几个项目需要考虑：
- 身份验证器应用程序：TOTP 使用行业标准算法生成基于时间的令牌。用户可以使用任意数量的移动应用程序生成令牌，包括：Citrix SSO、Microsoft Authenticator 和其他人。
- 令牌计数：每个用户帐户允许用户使用一个令牌（密钥）。
- 设备计数：尽管用户只能使用单个令牌（密钥），但用户可以在多个设备上安装令牌。但是，安装必须在注册阶段进行，因为用户在注册完成后无法透露二维码或密钥。
- 设备更换：无论何时用户更换移动设备，他们都必须向 TOTP 服务注册该设备。当用户再次通过 TOTP 注册过程时，旧的密钥将被删除。使用旧密钥的任何设备都无法生成正确的令牌，导致 Workspace 身份验证失败。
- 令牌重置：管理员可以手动重置用户的令牌。重置后，如果不重新注册 TOTP 服务，用户将无法完成身份验证。
- 部署：与所有身份和访问管理配置更改一样，在 Workspace 订阅上启用 TOTP 会影响所有用户。启用后，任何新的身份验证尝试都将失败，直到用户成功注册到 TOTP 服务。
TOTP Tech Insight 视频 提供了有关用户和管理员体验的更多详细信息。
Azure Active Directory
Citrix Workspace 允许用户使用 Azure Active Directory 帐户进行身份验证。身份验证可以像用户名和密码一样简单，也可以使用 Azure Active Directory 中可用的任何多因素身份验证策略。Citrix Workspace 和 Azure Active Directory 之间的集成导致 Azure Active Directory 在为用户返回身份令牌的同时处理身份验证过程。
要集成 Citrix Workspace 和 Azure Active Directory，Citrix Workspace 会自动在 Azure 中创建企业应用程序并设置正确的权限。这些权限包括以下（只读功能）：
- 登录并阅读用户个人资料
- 阅读所有用户的基本档案
- 阅读所有用户的完整资料
- 读取目录数据
- 阅读所有群组
Azure Active Directory 对用户进行身份验证。成功对用户进行身份验证后，Azure 将向 Citrix Workspace 提供 Azure 身份令牌，其中包括关于用户的声明，以便在正确的目录中唯一标识他们。
Citrix Workspace 利用 Azure Active Directory 声明授权用户访问 Citrix Workspace 内的资源和服务。
授权访问资源需要单一的“真相来源”。真相的来源是授权决定的最终权威。使用 Azure Active Directory 作为主用户目录时，Workspace 资源的类型决定了真实来源。
- Endpoint Management 服务：对于移动应用程序，Endpoint Management 服务使用 Active Directory 作为事实来源。当 Azure Active Directory 是 Workspace 的身份提供程序时，Azure Active Directory 身份必须包含特定的 Active Directory 声明（SID、UPN 和不会更改的 ImmutableID ）。这些声明将 Azure Active Directory 身份与 Active Directory 身份关联起来。如果 Endpoint Management 服务使用组成员资格，Active Directory 就是真实来源。
- 网关服务：对于 SaaS 和 Web 应用程序，Gateway 服务使用 Azure Active Directory 作为事实来源。Gateway 服务能够使用 Azure Active Directory 用户帐户或 Azure Active Directory 用户组成员资格来授权对资源的访问权限。
- Citrix DaaS：由于基于 Windows 的资源 (VDI) 需要基于 Active Directory 的用户身份，因此事实来源取决于底层的 Active Directory 和 Azure Active Directory 集成。
- Azure Active Directory 用户身份必须包含特定的 Active Directory 声明（SID、UPN 和不变的 ImmutableID ）。 这些声明将 Azure Active Directory 身份与 Active Directory 身份关联起来。对于特定用户身份，Azure Active Directory 是事实来源。
- 如果授权决策是基于组成员资格，则真实来源是 Active Directory。Workspace 随后通过 Cloud Connector 向 Active Directory 发送组成员资格请求。
使用 Azure Active Directory 同步工具大大简化了将 Active Directory 参数与 Azure Active Directory ID 关联的过程。
Azure Active Directory 技术洞察视频 提供了有关使用 FIDO2 YubiKey 时的管理员配置和用户体验的更多详细信息。
Citrix Gateway
用户可以使用本地 NetScaler Gateway 向 Citrix Workspace 进行身份验证。NetScaler Gateway 身份验证适用于使用单一来源进行用户身份验证的简单身份验证策略（例如 Active Directory）以及依赖多个身份验证提供程序和策略的更复杂的级联身份验证策略。
Citrix Workspace 和 NetScaler Gateway 之间的集成导致 NetScaler Gateway 处理初始身份验证过程。NetScaler Gateway 验证用户的身份验证后，Workspace 将在生成授权服务和资源的列表之前验证 Active Directory 凭据。
要集成 Citrix Workspace 和 NetScaler Gateway，必须在本地 NetScaler Gateway 中创建 OAuth IdP 策略，该策略是基于 OAuth 2.0 规范的身份验证协议。Citrix Workspace 连接到组织的唯一 NetScaler Gateway URL 以通过引用应用程序的客户端 ID（受共享密钥保护）来访问 OpenID。
在 NetScaler Gateway 上配置的 OpenID Connect 应用程序使用绑定到身份验证虚拟服务器的高级身份验证策略来验证用户身份。成功向 NetScaler Gateway 对用户进行身份验证后，NetScaler Gateway 会将用户的 Active Directory 凭据返回给 Citrix Workspace。
NetScaler Gateway 技术见解视频提供了有关管理员配置和用户体验的更多详细信息。
通过使用 nFactor，NetScaler Gateway 允许组织创建更加动态的身份验证流程，同时考虑用户组成员身份、设备所有权和用户位置等特征。
在一个示例中，使用最基本的配置，组织可以将 NetScaler Gateway 与 Citrix Workspace 集成，以向 Active Directory 提供身份验证。
此类配置需要使用 Citrix Workspace 配置的 OAuth IdP 策略和为本地 Active Directory 域配置的 LDAP 策略。但是，此基本身份验证策略可在不使用 NetScaler Gateway 的情况下完成。
在许多组织中，用户必须先对 RADIUS 部署（如 DUO）进行身份验证才能对 Active Directory 进行身份验证，以帮助保护 Active Directory 凭据。
此配置需要身份验证策略首先验证 RADIUS 身份验证。如果成功，身份验证流程将继续到下一个身份验证因素，即 LDAP 身份验证。
使用 NetScaler Gateway，组织可以实施上下文身份验证，其中用户的身份验证流程取决于当前用户上下文。例如，组织可以对企业拥有的设备和用户拥有的设备实施不同的身份验证策略。
在此配置中，Citrix Workspace 将身份验证请求发送到 NetScaler Gateway。NetScaler Gateway 请求基于客户端的证书，该证书仅在公司拥有的设备上可用。如果证书可用且有效，用户只需提供 Active Directory 密码即可。但是，如果证书无效或不存在（对于用户拥有的设备来说是这种情况），NetScaler Gateway 会挑战用户提供 TOTP 代码，然后提供 Active Directory 凭据。
另一个上下文身份验证示例根据 Active Directory 组成员资格提供了不同的身份验
与财务数据、个人数据或知识产权数据进行交互的用户应遇到更严格的身份验证策略，如图中 Group2 所示。
使用本地 NetScaler Gateway 作为身份提供者时，用户可以在 Citrix Workspace 中使用基于推送的身份验证，如 推送身份验证技术洞察视频中所述。
无论配置的身份验证策略类型如何，一旦用户成功验证其身份，NetScaler Gateway 都必须使用用户的 Active Directory 凭据响应初始 Citrix Workspace 请求。为了使 Citrix Workspace 完成身份验证过程并生成授权资源的列表，每个 Active Directory 用户帐户必须定义以下参数：
- 电子邮件地址
- 显示名称
- 常见的名字
- sAMAccountName
- 用户主体名称
- 对象标识符 (OID)
- 安全标识符 (SID)
Okta
配置后，用户可以使用 Okta 凭据向 Citrix Workspace 进行身份验证。身份验证可以像用户名和密码一样简单，也可以使用 Okta 中可用的任何多因素身份验证策略。Citrix Workspace 和 Okta 之间的集成导致 Okta 处理身份验证过程，同时返回用户的身份和访问令牌。
要集成 Citrix Workspace 和 Okta，必须在 Okta 内创建 OpenID Connect 应用程序。Citrix Workspace 连接到组织的唯一 Okta URL 以通过引用应用程序的客户端 ID（受共享密钥保护）来访问 OpenID。
OpenID Connect 应用程序会验证用户身份。一旦用户成功通过 Okta 身份验证，Okta 会为 Citrix Workspace 提供两个安全令牌：
- 访问令牌：证明用户有权访问 Okta 资源（OpenID Connect 应用程序）的令牌，无需持续重新进行身份验证。
- 身份令牌：证明用户身份的令牌。身份令牌包含有关经过身份验证的用户的声明（信息）。该令牌被编码以证明它没有被篡改。
这些令牌允许 Citrix Workspace 访问 OpenID Connect 应用程序，并根据用户的 Okta 身份生成授权资源列表。
授权访问资源需要单一的“真相来源”。真相的来源是授权决定的最终权威。使用 Okta 作为主要用户目录时，Workspace 资源的类型决定了事实来源。
- Endpoint Management 服务：对于移动应用程序，Endpoint Management 服务使用 Active Directory 作为事实来源。当 Okta 是 Workspace 的主要身份提供商时，Okta 身份必须包含特定的 Active Directory 声明（SID、UPN 和 GUID）。 这些声明将 Okta 身份与 Active Directory 身份关联起来。 如果 Endpoint Management 服务使用组成员资格，Active Directory 就是真实来源。
- Gateway 服务：对于 SaaS 和 Web 应用程序，Gateway 服务使用 Okta 作为事实来源。Gateway 服务能够使用 Okta 用户帐户或 Okta 用户组成员资格授权访问资源。
- Citrix DaaS：由于基于 Windows 的资源 (VDI) 需要基于 Active Directory 的用户身份，因此事实来源取决于底层的 Active Directory 和 Okta 集成。
- Okta 用户身份必须包含特定的 Active Directory 声明（SID、UPN 和 GUID）。 这些声明将 Okta 身份与 Active Directory 身份关联起来。对于特定的用户身份，Okta 是真相的来源。
- 如果授权决策基于组成员身份，则真实来源将基于 Active Directory 和 Okta 之间的同步参数。如果任何 Active Directory 组与 Okta 同步并包含 Active Directory 声明 (SID)，那么 Okta 将成为使用 objectSID 属性的组的真实来源。 此 Okta 属性仅针对 O kta 规范定义的 Active Directory 组返回。 本地 Okta 组不会设置此属性，从而导致 Active Directory 成为事实来源。Workspace 随后通过 Cloud Connector 向 Active Directory 发送组成员资格请求。
使用 Okta Active Directory 同步工具大大简化了将 Active Directory 参数与 Okta ID 关联的过程。Active Directory 声明必须遵守 Okta 内的以下命名标准。
