技术简介:工作区单点登录
用户的主Workspace标识授权他们访问SaaS、移动、web、虚拟应用程序和虚拟桌面。许多已授权的资源需要另一种身份验证，这种身份验证通常与用户的主要工作空间身份不同。Citrix Workspace通过提供对辅助资源的单点登录为用户提供了无缝的体验。
主身份
理解用户的主标识和辅助标识之间的差异为理解Workspace单点登录提供了基础。
首先，Citrix Workspace允许每个组织从不断增长的选项列表中选择一个主要身份，目前包括:
- Windows Active Directory
- Azure Active Directory
- Okta
- Citrix网关
- 谷歌
在Citrix Workspace中，用户的主要身份有两个用途:
- 将用户身份验证到Citrix Workspace
- 授权用户访问Citrix Workspace中的一组资源
一旦用户使用主标识成功地对Citrix Workspace进行身份验证，他们就拥有了对所有辅助资源的授权。对于组织来说，为用户的主身份设置强身份验证策略是至关重要的。
许多身份提供程序包括强大的身份验证策略选项，帮助保护用户对Citrix Workspace的主身份验证。在身份提供程序只包含单个用户名和密码的情况下，例如Active Directory, Citrix Workspace包含额外的功能来提高主身份验证安全性，例如基于时间的一次性密码．
要更深入地了解Citrix Workspace的主要标识，请参考工作空间识别技术简介．
二次身份
用户在Citrix Workspace中访问的许多应用程序、桌面和资源都使用另一组用户凭据(称为辅助身份)来保护。许多辅助身份与用户的主要身份不同。
单点登录微服务使用适当的方法将用户的主工作空间标识转换为特定于资源的标识，例如:
- SAML
- Kerberos
- 形式
- 虚拟智能卡)
使用Citrix Workspace，用户使用其主身份进行一次身份验证，然后自动满足对辅助资源的所有后续身份验证挑战。
Citrix Workspace如何提供对不同资源的单点登录取决于所访问资源的类型。为了更好地理解不同的方法，最好将其分解为以下主题:
- SaaS应用程序
- 网络应用程序
- 移动应用程序(部分即将推出)
- 虚拟应用程序和桌面
- 国内流离失所者链接
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应用程序的访问
- 管理员可以将用户的主标识建立在支持的不断增长的标识提供程序列表上
为了保证访问安全，组织必须
- 为主工作区标识实现强身份验证策略
- 禁用使用辅助身份直接访问SaaS应用程序
SSO: Web应用程序
web应用程序是由组织托管和管理的基于浏览器的应用程序。web应用程序托管在本地数据中心内。要访问web应用程序，用户必须与主机建立安全连接，并使用与web应用程序相关联的一组凭据进行身份验证，这些凭据称为辅助身份。
基于概念架构，网关连接器建立到组织的Citrix Cloud订阅的出站控制通道连接。一旦建立了对本地web应用程序的身份验证和访问请求，就会通过网关连接器的控制通道传输，从而消除了对VPN连接的需求。
根据web应用程序的不同，辅助标识可以是与用于向Citrix Workspace进行身份验证的主标识相同的标识，也可以是由不同标识提供者管理的唯一标识。
为了实现web应用程序的单点登录，Citrix Workspace在主身份(用于登录Citrix Workspace)和辅助身份(用于登录web应用程序)之间联合身份。web应用程序的SSO过程利用多种方法来支持更多的web应用程序。这些方法可以是
- Basic -当web应用服务器向用户呈现Basic -401挑战时使用。基本身份验证利用用于对Citrix Workspace进行身份验证的凭据。
- Kerberos——在web应用服务器向用户提出协商401挑战时使用。Kerberos使用用于对Citrix Workspace进行身份验证的凭据。
- 表单——当web应用服务器向用户提供HTML身份验证表单时使用。基于表单的身份验证要求管理员在身份验证页面上为用户名和密码识别适当的字段。
- SAML——当web应用程序服务器能够使用基于SAML的身份验证时使用，其中web应用程序充当服务提供者，Citrix Workspace充当身份提供者。用于登录到Citrix工作区的用户的主要身份必须具有与web应用程序中的凭据一致的参数(UPN或电子邮件)。要了解有关基于saml的单点登录的更多信息，请参阅SSO到SaaS应用部分。
- 无单点登录—当web应用服务器不需要用户身份验证或管理员希望用户手动登录时使用。
Citrix工作空间内的web应用程序单点登录帮助解决了一些用户和管理体验挑战:
- 用户不必为每个web应用程序记住用户名和密码
- 用户不必为每个web应用程序创建复杂的密码
- 用户不必为每个web应用程序设置/配置MFA密钥/令牌
- 用户访问内部web应用时，不需要启动VPN连接
- 管理员可以通过禁用用户的主身份来禁用对所有web应用程序的访问
- 管理员可以将用户的主标识建立在支持的不断增长的标识提供程序列表上
- 部署后，管理员不必更新网关连接器。Citrix Cloud服务可以根据需要自动更新。
为了保证访问安全，组织必须
- 为主工作区标识实现强身份验证策略
- 关闭对web应用的VPN访问
部署冗余网关连接器以在更新连接器时保持可用性。一次只更新一个连接器，并且在收到成功结果之前，该过程不会继续。
单点登录:虚拟应用和桌面
Citrix虚拟应用程序和桌面允许用户远程访问基于Windows和linux的应用程序和桌面。要访问基于windows的虚拟应用程序或桌面，需要用户使用Active Directory身份进行身份验证。
当用户的主工作区标识为Active Directory时，虚拟应用程序和桌面会话利用直通身份验证提供对辅助资源的单点登录。但是，如果组织希望使用非基于Active 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的虚拟应用程序和桌面的总体过程如下:
本例假设Citrix虚拟应用程序和桌面是本地部署。
如果组织使用基于云的Citrix虚拟应用程序和桌面服务，其架构类似于以下:
在Citrix Workspace中SSO到基于windows的虚拟应用程序和桌面有助于解决一些用户和管理体验挑战:
- 用户在访问虚拟应用程序或桌面时没有收到身份验证提示
- 用户不必为其Active Directory标识创建、更新和记住复杂的密码
- 管理员可以通过禁用用户的主身份来禁用对所有虚拟应用程序和桌面的访问
要正确集成联邦身份验证服务，请考虑以下事项:
- 同步:主工作区标识必须与基于Active directory的辅助标识保持同步。许多主标识提供程序都包含Active Directory同步工具，以帮助维护主标识和辅助标识之间的同步。如果没有适当的同步，联邦身份验证服务将无法将Active Directory标识关联到虚拟智能卡。
- Smartcard Only Authentication:通过组策略对象，管理员可以强制Smartcard Only Authentication。这消除了用户试图通过使用辅助标识的用户名/密码凭证绕过受保护的主标识的可能性。但是，如果用户必须使用用户名/密码以交互方式登录到服务，则启用此策略设置后身份验证将失败。
- 虚拟智能卡安全性:确保联邦身份验证服务基础设施得到适当的管理和保护是很重要的。下面的文章提供了联邦身份验证服务的安全性建议．
- 冗余:在生产部署中，整个体系结构必须将容错作为设计的一部分。这包括冗余的联合身份验证服务服务器、证书颁发机构等等。根据环境的规模，组织可能需要指定从属证书颁发机构，而不是指向根证书颁发机构。
- 证书颁发机构:对于生产部署，组织必须设计证书颁发机构来处理规模。此外，组织必须正确设计相关的证书撤销列表(CRL)基础设施，以克服潜在的服务中断。
- 三级身份验证:在虚拟桌面会话中，许多内部网站要求用户使用Active Directory身份进行身份验证。用于虚拟桌面单点登录的虚拟智能卡，也可以用于内部网站单点登录。联邦身份验证服务允许(通过组策略对象)使用会话内证书，其中虚拟智能卡被放置在用户证书存储区中。该功能提供了对这些第三资源的单点登录。
单点登录:IdP链接
许多组织目前依赖第三方解决方案(Okta、Ping、Azure等)来提供SaaS应用程序的单点登录。Citrix Workspace可以通过称为IdP链的过程将支持sso的SaaS应用程序集成到用户的资源提要中。IdP链实质上是将一个SAML断言转换为另一个SAML断言。IdP链允许组织在与Citrix Workspace完全集成的同时维护其当前的SSO提供程序，包括实现增强的安全策略。
当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充当服务提供者。当SSO提供程序担任服务提供程序角色时，将使用特定于应用程序的URL作为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-to-Okta
- Okta-to-Workday
这将产生以下认证流程:
创建IdP链允许组织维护其当前的SSO提供程序，同时仍然统一Citrix Workspace中的所有资源。