技术简报：Workspace 单点登录
用户的主工作区身份授权他们访问 SaaS、移动设备、Web、虚拟应用程序和虚拟桌面。许多授权资源需要另一种身份验证，其身份通常不同于用户的主工作区身份。Citrix Workspace 通过向辅助资源提供单点登录，为用户提供无缝体验。
主要身份
了解用户的主身份和辅助身份之间的差异为了解空间单点登录奠定了基础。
首先，Citrix Workspace 允许每个组织从不断增长的选项列表中选择主身份，该列表当前包括：
- Windows Active Directory
- Azure Active Directory
- Okta
- Citrix Gateway
在 Citrix Workspace 中，用户的主身份有两个用途：
- 对 Citrix Workspace 进行用户身份验证
- 授权用户访问 Citrix Workspace 中的一组资源
用户使用主身份成功向 Citrix Workspace 进行身份验证后，他们将获得对所有辅助资源的授权。组织必须为用户的主要身份设置强身份验证策略。
许多身份提供商都包含强身份验证策略选项，有助于保护用户对 Citrix Workspace 的主身份验证。如果身份提供程序仅包含单个用户名和密码（如 Active Directory），Citrix Workspace 会提供额外的功能来提高主身份验证的安全性，例如基于时间的一次性密码。
要更深入地了解 Citrix Workspace 的主要身份，请参阅工作空间身份技术简介。
次要身份
用户在 Citrix Workspace 中访问的许多应用程序、桌面和资源都使用另一组用户凭据（称为辅助身份）进行保护。许多次要身份与用户的主身份不同。
单点登录 µ-service 使用以下适当的方法将用户的主工作空间身份转换为资源特定的身份：
- SAML
- Kerberos
- 表单
- 虚拟智能卡
借助 Citrix Workspace，用户可以使用其主要身份进行一次身份验证，并自动满足后续对辅助资源的所有身份
Citrix Workspace 如何向不同资源提供单点登录取决于访问的资源类型。为了更好地理解不同的方法，最好将其分解为以下主题：
- SaaS 应用程序
- 网络应用程序
- 移动应用程序（部分即将推出）
- 虚拟应用程序和桌面
- IdP 链接
SSO：SaaS 应用
从 Citrix Workspace 的角度来看，SaaS 应用程序是由第三方托管在云中的基于浏览器的应用程序。要访问应用程序，用户必须使用与 SaaS 应用程序关联的一组凭证进行身份验证，称为辅助身份。
为了实现 SaaS 应用程序的单点登录，Citrix Workspace 会在主身份和辅助身份之间联合身份。SSO 流程使用了行业标准的基于 SAML 的身份验证。
基于 SAML 的身份验证通常侧重于三个主要实体：
- 身份提供者：SAML 链接中提供证明用户身份有效的实体
- 服务提供商：SAML 链接中的实体基于辅助身份提供服务（SaaS 应用程序）
- 断言：提供的数据包
基于 SAML 的身份验证通过将两个不同的用户帐户（主帐户和辅助用户帐户）与通用属性（通常是用户主体名称 (UPN) 或电子邮件地址关联起来的。
用户身份可以在来自身份提供商的主身份和来自服务提供商的辅助身份之间不同。
使用单点登录，用户不需要知道其辅助身份的用户 名或密码。此外，当身份验证使用 SAML 时，许多 SaaS 应用程序都能够禁用用户帐户的密码（和直接密码访问）。这将强制用户身份验证始终使用身份提供商的主身份，而不是服务提供商的辅助身份。
Citrix Workspace 为 SAML 流程引入了第四个组件
- 身份代理：将多个身份提供商链接到多个服务提供商的实体 (Citrix Workspace)
在 SAML 链接中，需要有一个实体充当服务提供商 (SP) 和身份提供商 (IdP)。IdP 不必包含主用户帐户身份。在此示例中，主用户身份包含在主用户目录 (Dir) 中。
作为身份代理 (IdB) 时，Citrix Workspace 会接受有关用户主要身份的声明，并将其转换为辅助身份。
将身份代理 (IdB) 添加到 SAML 身份验证流程中仍需要一个通用属性，将用户的主身份 (IdP) 链接到辅助身份 (SP)。
为使 SAML 身份验证起作用，身份代理会将请求与每个 SaaS 应用程序的 SAML 特定登录 URL 关联起来。此 URL 接收用户断言。当服务提供商收到断言时，它必须针对生成断言的实体（即身份代理的 SAML 发布者 URL）验证断言。
在 Citrix Workspace 中，单点登录 SaaS 应用程序的总体过程如下：
Citrix Workspace 中的 SSO 到 SaaS 应用程序有助于解决一些用户和管理员体验难题：
- 用户不必记住每个辅助身份的用户名和密码
- 用户不必为每个辅助身份创建复杂的密码
- 用户不必为每个辅助身份设置/配置 MFA 密钥/令牌
- 管理员可以通过禁用用户的主身份来禁用对所有 SaaS 应用的访问
- 管理员可以将用户的主要身份基于不断增长的受支持身份提供商列表之一
为了确保访问安全，组织必须
- 为主 Workspace 身份实施强身份验证策略
- 禁用具有辅助身份的 SaaS 应用程序的直接访问
SSO：Web 应用程序
Web 应用程序是由组织托管和管理的基于浏览器的应用程序。 Web 应用程序托管在本地数据中心内。要访问 Web 应用程序，用户必须建立与主机的安全连接，并使用与 Web 应用程序关联的一组凭据（称为辅助身份）进行身份验证。
基于概念体系结构，网关连接器建立到组织的 Citrix Cloud 订阅的出站控制通道连接。一旦建立了对本地 Web 应用程序的身份验证和访问请求，就会通过 Gateway Connector 的控制通道传输，从而无需 VPN 连接。
根据 Web 应用程序的不同，辅助身份可能与用于向 Citrix Workspace 进行身份验证的主身份相同，也可能是由其他身份提供商管理的唯一身份。
为了实现对 Web 应用程序的单点登录，Citrix Workspace 会在主身份（用于登录 Citrix Workspace）和辅助身份（用于登录 Web 应用程序）之间联合身份。Web 应用程序的 SSO 流程利用多种方法来支持更多的 Web 应用程序。 这些方法可以是
- 基本-当 Web 应用程序服务器向用户提出基本 401 挑战时使用。基本身份验证使用用于向 Citrix Workspace 进行身份验证的凭据。
- Kerberos-当 Web 应用程序服务器向用户提出协商 401 挑战时使用。Kerberos 使用用于向 Citrix Workspace 进行身份验证的凭据。
- 表单-当 Web 应用程序服务器向用户提供 HTML 身份验证表单时使用。基于表单的身份验证要求管理员在身份验证页面上识别用户名和密码的相应字段。
- SAML-当 Web 应用程序服务器能够使用基于 SAML 的身份验证时使用，其中 Web 应用程序充当服务提供商，Citrix Workspace 充当身份提供商。用于登录 Citrix Workspace 的用户的主身份必须具有与 Web 应用程序中的凭据一致的参数（UPN 或电子邮件）。要详细了解基于 SAML 的单点登录，请查看SSO 到 SaaS 应用程序部分。
- 无 SSO-在 Web 应用程序服务器不要求用户身份验证或管理员希望用户手动登录时使用。
Citrix Workspace 中的 Web 应用程序的单点登录有助于解决一些用户和管理员体验难题：
- 用户不必记住每个 Web 应用程序的用户名和密码
- 用户不必为每个 Web 应用程序创建复杂的密码
- 用户不必为每个 Web 应用程序设置/配置MFA 密钥/标记
- 用户不必启动 VPN 连接即可访问内部 Web 应用程序
- 管理员可以通过禁用用户的主要身份来禁用对所有 Web 应用程序的访问
- 管理员可以将用户的主要身份基于不断增长的受支持身份提供商列表之一
- 部署后，管理员无需更新网关连接器。Citrix Cloud 服务可根据需要自动执行更新。
为了确保访问安全，组织必须
- 为主 Workspace 身份实施强身份验证策略
- 禁用对 Web 应用程序的 VPN 访问
部署冗余网关连接器以在更新连接器时保持可用性。一次只更新一个连接器，在收到成功结果之前，该过程不会继续下去。
SSO：Virtual Apps and Desktops
Citrix Virtual Apps and Desktops 允许用户远程访问基于 Windows 和 Linux 的应用程序和桌面。要访问基于 Windows 的虚拟应用程序或桌面，用户需要使用 Active Directory 标识进行身份验证。
当用户的主 Workspace 标识为 Active Directory 时，虚拟应用程序和桌面会话利用直通身份验证提供对辅助资源的单点登录。但是，如果组织希望将基于非活动 Directory 的身份提供程序用于用户的主身份，Citrix Workspace 的单点登录功能必须将主身份转换为 Active Directory 辅助身份。
为了实现对虚拟应用程序和桌面的单点登录，Citrix Workspace 使用联合身份验证服务，该服务为用户动态生成基于 Active Directory 的虚拟智能卡。
在生成虚拟智能卡之前，Workspace 必须能够通过一组通用属性将用户的主身份与基于 Active Directory 的辅助身份关联起来。
例如，当 Okta 是 Citrix Workspace 的主要身份时，用户的 Okta 身份必须包含三个额外的参数（cip_sid、cip_upn 和 cip_oid）。这些参数将 Active Directory 标识与 Okta 身份关联起来。
用户成功通过主身份验证后，Citrix Workspace 中的单点登录功能将使用参数请求虚拟智能卡。
在 Citrix Workspace 中，单点登录到基于 Windows 的虚拟应用程序和桌面的总体过程如下：
SSO 到 Citrix Virtual Apps and Desktops](/en-us/tech-zone/learn/media/tech-briefs_workspace-sso_cvad-flow.png)
此示例假定 Citrix Virtual Apps and Desktops 是本地部署。
如果组织使用基于云的 Citrix Virtual Apps and Desktops Service，则体系结构类似于以下内容：
Citrix Workspace 中的 SSO 到基于 Windows 的虚拟应用程序和桌面有助于解决一些用户和管理员体验难题：
- 用户在访问虚拟应用程序或桌面时不会收到身份验证提示
- 用户不必为其 Active Directory 身份创建、更新和记住复杂的密码
- 管理员可以通过禁用用户的主身份来禁用对所有虚拟应用程序和桌面的访问
要正确集成联合身份验证服务，请考虑以下事项：
- 同步：主工作区标识必须与基于 Active Directory 的辅助身份保持同步。许多主要身份提供程序都包含 Active Directory 同步工具，以帮助维护主身份和辅助身份之间如果没有正确的同步，联合身份验证服务将无法将 Active Directory 身份与虚拟智能卡关联。
- 仅智能卡身份验证：使用组策略对象，管理员可以强制仅进行智能卡身份验证。这消除了用户试图通过使用辅助身份的用户名/密码凭据绕过受保护的主身份的可能性。但是，如果用户必须使用用户名/密码以交互方式登录服务，则在启用此策略设置的情况下，身份验证将失败。
- 虚拟智能卡安全：确保适当管理和保护联合身份验证服务基础架构非常重要。以下文章为联合身份验证服务提供了安全建议。
- 冗余：在生产部署中，整体体系结构必须将容错纳入设计的一部分。这包括冗余的联合身份验证服务器、证书颁发机构等。根据环境的规模，组织可能需要专门指定下属证书颁发机构，而不是指向根证书颁发机构。
- 证书颁发机构：对于生产部署，组织必须设计证书颁发机构来处理规模。此外，组织必须正确设计相关的证书吊销列表 (CRL) 基础架构，以克服潜在的服务中断。
- 三级身份验证：在虚拟桌面会话中，许多内部网站都要求用户使用 Active Directory 身份进行身份验证。用于向虚拟桌面提供单点登录的虚拟智能卡可用于提供对内部网站的单点登录。联合身份验证服务允许（通过组策略对象）会话中的证书，其中虚拟智能卡放置在用户证书存储区中。此功能提供对这些第三级资源的单点登录。
SSO：IdP 链接
许多组织目前依赖第三方解决方案（Okta、Ping、Azure 等）来提供 SaaS 应用程序的单点登录。Citrix Workspace 可以通过名为 IdP 链接的过程将启用 SSO 的 SaaS 应用程序集成到用户的资源源中。IdP 链接基本上将一个 SAML 断言转换为另一个 SAML 断言。IdP 链接使组织能够维护其当前的 SSO 提供商，同时与 Citrix Workspace 完全集成，包括实施增强的安全策略。
当 Citrix Workspace 向 SaaS 应用程序提供 SSO 时，它将使用 SAML 身份验证。基于 SAML 的身份验证通过将两个不同的用户帐户（主帐户和辅助用户帐户）与通用属性（通常是用户主体名称 (UPN) 或电子邮件地址关联起来的。
使用基于 SAML 的单点登录，有两个合作伙伴：
- 服务提供商 (SP)：提供服务并包含辅助身份的实体
- 身份提供程序 (IdP)：为用户的主要身份提供验证的实体。SAML 组中的身份提供商不必是用户身份的最终权威机构。
主用户目录是对用户身份的最终权威。Citrix Workspace 充当身份代理 (IdB)，从主用户目录 (Dir) 获取关于用户的声明，以创建 SAML 断言。该断言向服务提供商 (SP) 证明用户的身份并完成了单点登录过程。
当组织已经使用了另一个 SSO 提供商时，IdP 链接会将额外的 SAML 身份验证链接添加到身份验证链中。
在此 IdP 链接示例中，Citrix Workspace 作为身份代理对用户进行主要用户目录的身份验证。在第一个 SAML 链接中，Citrix Workspace 利用有关用户的声明为作为服务提供商的特定于 Okta 的资源创建 SAML 断言。在第二个 SAML 链接中，Okta 利用关于用户的声明为特定 SaaS 应用程序（即服务提供商）创建 SAML 断言。
IdP 链接会在用户的主身份和请求的服务之间添加其他链接。在每个 SAML 链接中，身份提供商和服务提供商之间的通用属性必须相同。当身份验证通过链中的不同链接时，公共属性可能会发生变化。
在每个 SAML 链接中，身份提供商会将身份验证请求与每个 SaaS 应用程序的 SAML 特定登录 URL 关联起来。此 URL 接收用户断言，其中包括公共属性。当服务提供商收到断言时，它必须针对生成断言的实体（即身份提供商的 SAML 发布者 URL）验证断言。
在 IdP 链中，除了 SSO 提供商中的每个启用 SSO 的应用程序都有一个特定于应用程序的 URL 之外，流程是相同的。应用程序特定的 URL 充当服务提供商。特定于应用程序的 URL 用作 SSO 提供商担任服务提供商角色时的 SAML 登录 URL。
在此示例中，当用户从 Citrix Workspace 中选择启用了 OKTA 的应用程序时，Citrix Workspace 会向请求的 Okta 应用程序的 SAML 登录 URL 显示断言。Okta 使用 Citrix Workspace 中的 SAML 发行者 URL 验证断言。成功后，Okta 会向 SaaS 应用程序的 SAML 登录 URL 提供断言，该 URL 使用 Okta SAML 发行者 URL 验证断言。
考虑 IdP 链接的最简单方法是单独关注链中的每个链路，其中包括一个身份提供商和一个服务提供商。在本例中，链中的链接是：
- Citrix 到 Okta
- Okta 到 Work
这将导致以下身份验证流程：
创建 IdP 链允许组织维护其当前的 SSO 提供程序，同时仍然统一 Citrix Workspace 中的所有资源。