技术简介:工作空间标识
用户的主要工作空间标识授权访问所有工作空间资源提要，包括微应用程序、移动应用程序、虚拟应用程序、虚拟桌面和内容。Citrix Workspace为组织提供了选择用户的主要标识提供者的选项。
身份提供者(IdP)
标识提供者是用户标识的最终权威。身份提供者负责保护和保护用户身份的策略，包括密码策略、多因素身份验证策略和锁定策略。
在云时代之前，组织对于身份提供者只有一个选择:Windows Active Directory。但是现在，几乎每个需要唯一用户帐户的系统或服务都像身份提供者一样工作。Facebook、LinkedIn、Twitter、Workday和谷歌都是身份认证提供商，因为每家公司在其服务中都是用户身份的最终权威。此外，一个常见的安全建议(很少有人遵循)是为每个身份使用不同的密码，以限制密码被盗的影响。
传统的身份识别方法提供了最糟糕的用户体验之一。用户经常被要求进行身份验证。用户被迫为每项服务记住唯一而复杂的密码。由于忘记凭据，用户正在花费宝贵的时间重置密码和解锁帐户。
Citrix Workspace为现状提供了更好的替代方案。Citrix Workspace允许每个组织从不断增长的选项列表中选择一个主标识，目前包括。
- Windows Active Directory
- Azure活动目录
- Okta
- Citrix网关
Citrix Workspace依赖于标识代理微服务来管理对已配置的标识提供程序的身份验证。一个成功的工作空间身份验证允许资源提要µ-服务创建一个用户可用的授权资源列表。
然而，这些服务中的许多具有(或需要)与用户的主要工作空间标识不同的标识，因为它们使用不同的标识提供程序。单点登录µ服务使用以下适当的方法将用户的主要工作空间标识转换为特定于资源的标识:
- SAML
- Kerberos
- 形式
- 虚拟智能卡)
使用主要和次要身份的Citrix Workspace方法创建了一种体验，在这种体验中，用户进行一次物理身份验证，随后的所有身份验证挑战都自动得到满足。
身份代理
身份提供者和相关的身份数据库是用户身份的最终权威。但是，每个标识提供程序都是不同的。每个标识提供程序都为用户标识集成了不同的参数、策略和标准。
在Citrix Workspace中，标识代理µ-service将主身份验证请求重定向到配置的标识提供程序。身份验证请求传递给身份提供程序后，身份提供程序中的身份验证策略将指定用户必须如何进行身份验证，这通常包括多因素身份验证策略。
一旦身份提供者成功地对用户进行身份验证，身份代理µ-服务就会收到一个成功的身份验证响应。这种方法的好处是，组织可以在不影响Citrix Workspace的情况下更改标识提供程序中的身份验证策略。
除了来自身份提供者的成功身份验证响应外，身份代理µ-服务还接收身份提供者的唯一信息，并将其转换为关于用户的标准声明集。
关于用户的声明只是标识用户的信息，可以是UPN、SID、GUID、电子邮件或身份提供者数据库中包含的任何其他信息。声明允许Citrix Workspace生成用户有权访问的资源和服务列表。例如，如果用户的主要身份是谷歌ID，则Citrix Workspace使用谷歌ID来控制对未链接到谷歌ID的其他资源和服务的授权，如Workday、SAP、Windows、Slack等。换句话说，使用Citrix Workspace，用户可以使用单个谷歌ID登录到每个授权资源，包括Windows。
在Citrix Workspace中，身份代理µ-服务继续扩展，包括主要身份提供者的其他选项。身份代理服务包括可以从本地位置获得的身份提供者，或者身份代理服务可以利用基于云的身份提供者。下图概述了Citrix Workspace标识平台和所有当前标识提供程序选项，稍后将更详细地讨论这些选项。
每个标识提供程序都是唯一的;但最后，每个身份提供者都会告诉Citrix Workspace关于用户的一些事情:
- 用户名
- 用户认证成功
- 关于用户的声明
为了更好地理解每个标识提供程序的详细信息，请查看下面关于主标识提供程序的部分
- 活动目录
- 带TOTP的活动目录
- Azure活动目录
- Citrix网关
- Okta
- 谷歌
活动目录
配置后，用户可以使用Active Directory凭据向Citrix Workspace进行身份验证。
要将Citrix Workspace与本地Active Directory域集成，Workspace必须能够与域控制器通信。通过在内部环境中部署一组高度可用的云连接器，云连接器与组织的Citrix cloud订阅建立出站控制通道。出站控制通道允许Citrix Workspace通过端口443与内部部署组件安全地进行隧道通信，而不需要修改入站防火墙端口。
云连接器包括一个AD提供者服务，该服务允许Citrix Workspace从Active Directory域读取用户和组信息。当用户使用Citrix Workspace进行身份验证时，凭据将通过云连接器的AD Provider服务发送到本地域控制器。
带TOTP的活动目录
对于许多组织来说，使用用户名和密码提供对应用程序和桌面服务的访问并不能提供足够的安全性。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注册过程时，旧的密钥将被删除。任何使用旧密钥的设备都无法生成正确的令牌，从而导致工作区身份验证失败。
- 令牌重置:管理员可以手动重置用户的令牌。重置后，用户如果不重新注册TOTP服务就无法完成身份验证。
- 部署:与所有标识和访问管理配置更改一样，在工作区订阅上启用TOTP会影响所有用户。启用后，任何新的身份验证尝试都会失败，直到用户成功注册到TOTP服务。
的TOTP科技洞察视频提供有关用户和管理体验的其他详细信息。
Azure活动目录
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作为主要用户目录时，工作区资源的类型决定了真相的来源。
- 内容协作服务:对于用户文件和内容，内容协作服务是真实的来源。当Azure Active Directory是Workspace的标识提供程序时，Azure Active Directory标识和内容协作帐户必须使用相同的电子邮件地址。对于组成员信息，内容协作服务是真相的来源。组成员信息基于用户的电子邮件地址。
- 端点管理服务:对于移动应用程序，端点管理服务使用活动目录作为真相的来源。当Azure Active Directory是Workspace的标识提供程序时，Azure Active Directory标识必须包含特定的活动目录声明(SID、UPN和ImmutableID这一点没有改变)。这些声明将Azure Active Directory标识与活动目录标识相关联。如果端点管理服务使用组成员关系，则活动目录是真相的来源。
- 网关服务:对于SaaS和web应用程序，网关服务使用Azure活动目录作为真相的来源。网关服务能够使用Azure Active Directory用户帐户或Azure Active Directory用户组成员资格来授权对资源的访问。
- 微应用程序服务:对于微应用程序，微应用程序服务使用Azure活动目录作为真相的来源。Microapps服务能够使用Azure Active Directory用户帐户或Azure Active Directory用户组成员资格来授权对资源的访问。
- 虚拟应用程序和桌面服务:由于基于windows的资源(VDI)需要基于活动目录的用户标识，因此真相的来源依赖于底层活动目录和Azure活动目录集成。
- Azure Active Directory用户标识必须包含特定的Active Directory声明(SID、UPN和ImmutableID这一点没有改变)。这些声明将Azure Active Directory标识与活动目录标识相关联。对于特定的用户身份，Azure Active Directory是真相的来源。
- 如果授权决策基于组成员关系，那么事实的来源是Active Directory。工作区随后通过云连接器向Active Directory发送组成员资格请求。
使用Azure Active Directory同步工具，将Active Directory参数与Azure Active Directory ID链接的过程大大简化了。
的Azure活动目录技术洞察视频提供了使用FIDO2 YubiKey时管理配置和用户体验的额外详细信息。
Citrix网关
用户可以使用内部部署的Citrix Gateway向Citrix Workspace进行身份验证。Citrix Gateway身份验证支持使用单一源进行用户身份验证的简单身份验证策略(如Active Directory)，也支持依赖多个身份验证提供者和策略的更复杂的级联身份验证策略。
Citrix Workspace和Citrix Gateway之间的集成导致Citrix Gateway处理初始身份验证过程。一旦Citrix Gateway验证了用户的身份验证，Workspace将在生成授权服务和资源列表之前验证Active Directory凭据。
要集成Citrix Workspace和Citrix Gateway，必须在内部部署的Citrix Gateway中创建OAuth IdP策略，这是一种基于OAuth 2.0规范的身份验证协议。Citrix Workspace连接到组织的唯一Citrix Gateway URL，通过引用应用程序的客户端ID来访问OpenID Connect应用程序，该应用程序受到共享秘密密钥的保护。
在Citrix Gateway上配置的OpenID Connect应用程序使用绑定到身份验证虚拟服务器的高级身份验证策略对用户进行身份验证。一旦用户成功地通过了Citrix Gateway的身份验证，Citrix Gateway将用户的Active Directory凭据返回到Citrix Workspace。
的思杰网关科技洞察视频提供有关管理配置和用户体验的其他详细信息。
使用nFactor， Citrix Gateway允许组织创建一个更动态的身份验证流程，考虑到用户组成员、设备所有权和用户位置等特征。
在一个示例中，使用最基本的配置，组织可以将Citrix Gateway与Citrix Workspace集成在一起，为Active Directory提供身份验证。
这种类型的配置需要使用Citrix Workspace配置OAuth IdP策略，并为本地Active Directory域配置LDAP策略。但是，这个基本的身份验证策略可以在不使用Citrix Gateway的情况下完成。
在许多组织中，用户在对Active Directory进行身份验证之前，必须对RADIUS部署(如DUO)进行身份验证，这有助于保护Active Directory凭据。
该配置要求认证策略首先验证RADIUS认证。如果成功，身份验证流将继续到下一个身份验证因素，即LDAP身份验证。
使用Citrix Gateway，组织可以实现上下文身份验证，其中用户的身份验证流程取决于当前用户上下文。例如，一个组织可以对公司拥有的设备和用户拥有的设备实施不同的认证策略。
在此配置中，Citrix Workspace将身份验证请求发送到Citrix Gateway。Citrix Gateway请求基于客户端的证书，该证书仅在公司拥有的设备上可用。如果证书可用且有效，用户只需提供一个Active Directory密码。但是，如果证书无效或不存在(这是用户拥有的设备的情况)，则Citrix Gateway要求用户提供TOTP代码和Active Directory凭据。
上下文身份验证的另一个示例基于Active Directory组成员关系提供不同的身份验证策略。
与财务数据、个人数据或知识产权数据交互的用户应该遇到更严格的身份验证策略，如图中的Group2所示。
在使用内部部署的Citrix Gateway作为身份提供者时，用户可以使用Citrix Workspace进行基于推送的身份验证，详情请参见推送认证技术洞察视频。
无论配置的身份验证策略类型如何，一旦用户成功验证了其身份，Citrix 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 Connect应用程序，该应用程序受到共享密钥的保护。
OpenID Connect应用程序对用户进行身份验证。一旦用户成功通过Okta的身份验证，Okta会为Citrix Workspace提供两个安全令牌:
- 访问令牌:证明用户有权访问Okta资源(OpenID Connect应用程序)的令牌，无需不断重新验证。
- 身份令牌:证明用户身份的令牌。标识令牌包含关于已验证用户的声明(信息)。对令牌进行编码以证明它没有被篡改。
这些令牌允许Citrix Workspace访问OpenID Connect应用程序，并根据用户的Okta标识生成授权资源列表。
授权访问资源需要一个单一的“真相来源”。真相的来源是授权决策的最终权威。当使用Okta作为主要用户目录时，Workspace资源的类型决定了真相的来源。
- 内容协作服务:对于用户文件和内容，内容协作服务是真实的来源。当Okta是Workspace的主要身份提供者时，Okta身份和内容协作帐户必须使用相同的电子邮件地址。对于组成员信息，内容协作服务是真相的来源。组成员信息基于用户的电子邮件地址。在这个场景中，Okta仅用作Workspace的标识提供程序。
- 端点管理服务:对于移动应用程序，端点管理服务使用活动目录作为真相的来源。当Okta是Workspace的主要标识提供者时，Okta标识必须包含特定的活动目录声明(SID、UPN和GUID)。这些声明将Okta标识与Active Directory标识相关联。如果端点管理服务使用组成员关系，则活动目录是真相的来源。
- 网关服务:对于SaaS和web应用程序，网关服务使用Okta作为真相来源。Gateway Service能够使用Okta用户帐户或Okta用户组成员资格来授权对资源的访问。
- Microapps Service:对于微应用程序，Microapps Service使用Okta作为真相来源。Microapps服务能够使用Okta用户帐户或Okta用户组成员资格来授权对资源的访问。
- 虚拟应用程序和桌面服务:因为基于windows的资源(VDI)需要基于Active Directory的用户标识，真相的来源依赖于底层Active Directory和Okta集成。
- Okta用户身份必须包含特定的活动目录声明(SID、UPN和GUID)。这些声明将Okta标识与Active Directory标识相关联。对于特定的用户身份，Okta是真相的来源。
- 如果授权决策基于组成员关系，则真实源基于Active Directory和Okta之间的同步参数。如果任何活动目录组与Okta同步并包含活动目录声明(SID)，那么Okta将成为使用objectSID属性的组的真实源。属性定义的活动目录组仅返回此Okta属性Okta规范．原生Okta组将没有此属性设置，从而导致Active Directory成为真相的来源。工作区随后通过云连接器向Active Directory发送组成员资格请求。
使用Okta Active Directory同步工具，将Active Directory参数与Okta ID链接的过程大大简化了。Active Directory声明必须在Okta中遵循以下命名标准。
中详细介绍了Okta作为标识提供程序的设置和配置Okta Tech Insight视频。