技术简报: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

Workspace 身份

Citrix Workspace 依靠身份代理微服务来管理对已配置的身份提供商的身份验证。成功的 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 身份平台和所有当前的身份提供商选项,稍后将对其进行更详细的讨论。

Workspace 身份概述

每个身份提供商都是独一无二的;但最终,每个身份提供商都会向 Citrix Workspace 告知 Citrix Workspace 一些关于用户的信息:

  1. 用户名
  2. 用户成功通过身份验证
  3. 关于用户的声明

要更好地了解每个身份提供商的详细信息,请查看以下有关主身份提供商的部分

  • Active Directory
  • 带 TOTP 的 Active Directory
  • Azure Active Directory
  • Citrix Gateway
  • Okta

Active Directory

配置后,用户可以使用 Active Directory 凭据对 Citrix Workspace 进行身份验证。

Active Directory IdP

要将 Citrix Workspace 与本地 Active Directory 域集成,Workspace 必须能够与域控制器通信。通过在本地环境中部署一组高度可用的 Cloud Connector,Cloud Connector 使用组织的 Citrix Cloud 订阅建立出站控制通道。出站控制通道允许 Citrix Workspace 通过端口 443 与本地组件安全地通过通道通信,而无需修改入站防火墙端口。

Cloud Connector 包括一个 AD 提供程序服务,允许 Citrix Workspace 从 Active Directory 域读取用户和组信息。当用户使用 Citrix Workspace 进行身份验证时,凭据将通过 Cloud Connector 的 AD 提供程序服务发送到本地域控制器。

Active Directory 端口

带 TOTP 的 Active Directory

对于许多组织来说,使用用户名和密码提供对应用程序和桌面服务的访问权限并不能提供足够的安全性。Citrix Workspace 采用云端交付的基于时间的一次性密码 (TOTP),通过引入“您拥有的东西”(TOTP 令牌)和“您知道的东西”(即密码)来提供多重身份验证。

TOTP 生成一个随机 6 位数代码,每 30 秒更改一次。此代码基于在用户的移动应用程序与后端基础结构之间共享的密钥。该密钥是多重身份验证的“您拥有的东西”因素。为了生成随机代码,将行业标准的安全哈希算法应用到密钥和当前时间。为了进行身份验证,将移动应用程序中的代码与来自后端基础结构的代码进行比较。

要在 TOTP 服务中注册,每个用户都会在移动设备上的身份验证器应用程序中创建并安装一个预共享密钥。

带 TOTP 注册功能的 Active Directory

用户成功在 TOTP 微服务中注册后,用户必须使用令牌以及其 Active Directory 凭据才能成功向 Citrix Workspace 进行身份验证。

采用 TOTP 身份验证的 Active Directory

由于 TOTP 已作为一项功能整合到 Citrix Workspace 中,因此消除了在本地环境中设置和维护 TOTP 类型的解决方案的复杂性。借助 Citrix Workspace 中的这一功能,管理员可以启用该服务,用户注册设备。

启用基于 TOTP 的多重身份验证时,需要注意以下几个事项:

  • 身份验证器应用程序:TOTP 使用行业标准算法生成基于时间的令牌。用户可以使用任意数量的移动应用程序生成令牌,包括:Citrix SSO、Microsoft Authenticator 等。
  • 令牌数量:每个用户帐户允许用户使用一个令牌(密钥)。
  • 设备数量:尽管用户只能使用一个令牌(密钥),但用户可以在多个设备上安装令牌。但是,安装必须在注册阶段进行,因为用户在注册完成后无法透露 QR 代码或密钥。
  • 设备更换:每当用户更换移动设备时,他们都必须向 TOTP 服务注册该设备。当用户再次完成 TOTP 注册过程时,旧密钥将被删除。任何使用旧密钥的设备都无法生成正确的令牌,导致 Workspace 身份验证失败。
  • 令牌重置:管理员可以手动重置用户的令牌。重置后,如果不向 TOTP 服务重新注册,用户将无法完成身份验证。
  • 部署:与所有身份识别和访问管理配置更改一样,在 Workspace 订阅上启用 TOTP 会影响所有用户。启用后,在用户成功向 TOTP 服务注册之前,任何新的身份验证尝试都将失败。

TOTP 技术洞察视频提供了有关用户和管理员体验的更多详细信息。

Azure Active Directory

Citrix Workspace 允许用户使用 Azure Active Directory 帐户进行身份验证。身份验证可以像用户名和密码一样简单,也可以使用 Azure Active Directory 中可用的任何多重身份验证策略。Citrix Workspace 与 Azure Active Directory 之间的集成导致 Azure Active Directory 在为用户返回身份令牌的同时处理身份验证过程。

Azure Active Directory IdP

为了将 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 资源的类型决定事实来源。

  • Content Collaboration 服务:对于用户文件和内容,Content Collaboration 服务是事实来源。当 Azure Active Directory 是 Workspace 的身份提供商时,Azure Active Directory 身份和 Content Collaboration 帐户必须使用相同的电子邮件地址。对于组成员身份信息,Content Collaboration 服务是事实来源。组成员身份信息基于用户的电子邮件地址。
  • 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 应用程序,网关服务使用 Azure Active Directory 作为事实来源。网关服务能够使用 Azure Active Directory 用户帐户或 Azure Active Directory 用户组成员身份来授权对资源的访问权限。
  • 微应用服务:对于微应用应用程序,微应用服务使用 Azure Active Directory 作为事实来源。微应用服务能够使用 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

用户可以使用本地 Citrix Gateway 对 Citrix Workspace 进行身份验证。Citrix Gateway 身份验证支持使用单一来源进行用户身份验证的简单身份验证策略(例如 Active Directory),以及依赖多个身份验证提供程序和策略的更复杂的级联身份验证策略。

Citrix Workspace 与 Citrix Gateway 之间的集成导致 Citrix Gateway 处理初始身份验证过程。Citrix Gateway 验证用户的身份验证后,Workspace 将在生成授权服务和资源列表之前验证 Active Directory 凭据。

Citrix Gateway IdP

要将 Citrix Workspace 与 Citrix Gateway 集成,必须在本地 Citrix Gateway 中创建 OAuth IdP 策略,这是一种基于 OAuth 2.0 规范的身份验证协议。Citrix Workspace 连接到组织唯一的 Citrix Gateway URL,通过引用 OpenID Connect 应用程序的客户端 ID(受共享密钥保护)来访问该应用程序。

在 Citrix Gateway 上配置的 OpenID Connect 应用程序使用绑定到身份验证虚拟服务器的高级身份验证策略对用户进行身份验证。用户成功通过 Citrix Gateway 的身份验证后,Citrix Gateway 将用户的 Active Directory 凭据返回给 Citrix Workspace。

Citrix Gateway 技术洞察视频提供了有关管理员配置和用户体验的更多详细信息。

通过使用 nFactor,Citrix Gateway 允许组织创建更动态的身份验证流程,同时考虑用户组成员身份、设备所有权和用户位置等特征。

举例说明:使用最基本的配置,组织可以将 Citrix Gateway 与 Citrix Workspace 集成,为 Active Directory 提供身份验证。

Citrix Gateway - Active Directory

这种类型的配置需要使用 Citrix Workspace 配置的 OAuth IdP 策略和为本地 Active Directory 域配置的 LDAP 策略。但是,无需使用 Citrix Gateway 即可完成此基本身份验证策略。

在许多组织中,用户在向 Active Directory 进行身份验证之前必须对 RADIUS 部署(例如 DUO)进行身份验证,这有助于保护 Active Directory 凭据。

Citrix Gateway - DUO

此配置要求身份验证策略首先验证 RADIUS 身份验证。如果成功,身份验证流程将继续到下一个身份验证因素,即 LDAP 身份验证。

使用 Citrix Gateway,组织可以实现上下文身份验证,其中用户的身份验证流程取决于当前的用户上下文。例如,组织可以对企业拥有的设备与用户拥有的设备实施不同的身份验证策略。

Citrix Gateway - 证书

在此配置中,Citrix Workspace 向 Citrix Gateway 发送身份验证请求。Citrix Gateway 请求基于客户端的证书,该证书仅在企业拥有的设备上可用。如果证书可用且有效,用户只需提供 Active Directory 密码即可。但是,如果证书无效或者不存在(用户拥有的设备就是这种情况),Citrix Gateway 会要求用户提供 TOTP 代码,然后提供 Active Directory 凭据。

上下文身份验证的另一个示例提供了基于 Active Directory 组成员身份的不同身份验证策略。

Citrix Gateway - 用户组

与财务数据、个人数据或知识产权数据交互的用户应该会遇到更严格的身份验证策略,如图中的 Group2 所示。

使用本地 Citrix Gateway 作为身份提供商时,用户可以在 Citrix Workspace 中使用基于推送的身份验证,如[推送身份验证技术洞察视频]中所述。(/en-us/tech-zone/learn/tech-insights/authentication-push.html)

无论配置了哪种类型的身份验证策略,一旦用户成功验证其身份,Citrix Gateway 都必须使用用户的 Active Directory 凭据响应初始 Citrix Workspace 请求。要使 Citrix Workspace 完成身份验证过程并生成授权资源列表,每个 Active Directory 用户帐户都必须定义以下参数:

  • 电子邮件地址
  • 显示名称
  • 公用名
  • sAMAccountName
  • 用户主体名称
  • 对象标识符 (OID)
  • 安全标识符 (SID)

Okta

配置后,用户可以使用 Okta 凭据对 Citrix Workspace 进行身份验证。身份验证可以像用户名和密码一样简单,也可以使用 Okta 中可用的任何多重身份验证策略。Citrix Workspace 与 Okta 之间的集成导致 Okta 在为用户返回身份和访问令牌的同时处理身份验证过程。

Okta IdP

要将 Citrix Workspace 与 Okta 集成,必须在 Okta 中创建 OpenID Connect 应用程序。Citrix Workspace 连接到组织唯一的 Okta URL,通过引用 OpenID Connect 应用程序的客户端 ID(受共享密钥保护)来访问该应用程序。

OpenID Connect 应用程序对用户进行身份验证。用户成功对 Okta 进行身份验证后,Okta 会向 Citrix Workspace 提供两个安全令牌:

  • 访问令牌:一种证明用户有权访问 Okta 资源(OpenID Connect 应用程序)的令牌,无需持续重新进行身份验证。
  • 身份令牌:证明用户身份的令牌。身份令牌包含有关经过身份验证的用户的声明(信息)。令牌经过编码以证明其没有被篡改。

这些令牌允许 Citrix Workspace 访问 OpenID Connect 应用程序,并根据用户的 Okta 身份生成授权资源列表。

授权访问资源需要一个“事实来源”。事实来源是授权决策的最终权威。使用 Okta 作为主用户目录时,Workspace 资源的类型决定事实来源。

  • Content Collaboration 服务:对于用户文件和内容,Content Collaboration 服务是事实来源。当 Okta 是 Workspace 的主身份提供商时,Okta 身份和 Content Collaboration 帐户必须使用相同的电子邮件地址。对于组成员身份信息,Content Collaboration 服务是事实来源。组成员身份信息基于用户的电子邮件地址。在这种情况下,Okta 仅用作 Workspace 的身份提供商。
  • Endpoint Management 服务:对于移动应用程序,Endpoint Management 服务使用 Active Directory 作为事实来源。当 Okta 是 Workspace 的主身份提供商时,Okta 身份必须包含特定的 Active Directory 声明(SID、UPN 和 GUID)。 这些声明将 Okta 身份与 Active Directory 身份相关联。 如果 Endpoint Management 服务使用组成员身份,Active Directory 就是事实来源。
  • 网关服务:对于 SaaS 和 Web 应用程序,网关服务使用 Okta 作为事实来源。网关服务能够使用 Okta 用户帐户或 Okta 用户组成员身份来授权对资源的访问权限。
  • 微应用服务:对于微应用应用程序,微应用服务使用 Okta 作为事实来源。微应用服务能够使用 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 规范定义的 Active Directory 组,才会返回此 Okta 属性。 本机 Okta 组不会设置此属性,导致 Active Directory 成为事实来源。随后,Workspace 通过 Cloud Connector 向 Active Directory 发送组成员身份请求。

使用 Okta 同步工具,大大简化了将 Active Directory 参数与 Okta Active Directory ID 关联的过程。Active Directory 声明必须遵守 Okta 中的以下命名标准。

Okta - 参数

[Okta 技术洞察视频]详细介绍了 Okta 作为身份提供商的设置和配置。(/en-us/tech-zone/learn/tech-insights/okta.html)

技术简报:Workspace 身份