单点登录支持
概况介绍
浏览器内容重定向现在通过单点登录支持提供简化的用户体验，从而实现 VDA 侧身份验证和 Cookie 共享。
此增强功能消除了冗余登录，通过在 BCR 会话中（即使在 BCR 窗口关闭后）保持身份验证和 Cookie 持久性来提高工作效率。
这种无缝体验通过确保身份验证源自 VDA 而非客户端，进一步增强了安全性。
未启用单点登录
- 在 BCR 中打开已通过身份验证的页面时，用户每次都需要重新输入其凭据，从而破坏了 SSO 持久性。
- SSO 仅在 BCR 窗口保持打开状态时才得以维持；关闭并重新打开窗口会强制用户重复登录过程。
- 身份验证流程从客户端发生，这迫使管理员从客户端设备向安全身份验证站点提供网络访问。
启用单点登录
- 用户不再需要输入凭据（当已在 VDA 上通过身份验证时），因为 SSO 会从 VDA 浏览器无缝保留。
- 身份验证从 VDA 发生，这通过限制客户端网络要求和暴露来改善安全状况，从而提供显著改进且不间断的体验。
所需最低要求
- Citrix 虚拟应用和桌面 2511
- 适用于 Windows 的 Citrix 工作空间应用程序 2511
- 适用于 Linux 的 Citrix 工作区应用程序 2511 (预览版)
- 浏览器重定向扩展 (Chrome 或 Edge) 25.11 或更高版本
支持的身份验证序列
目前支持两种类型的身份验证序列，可与 BCR 单点登录配合使用。
基于重定向的身份验证
在此标准方法中，应用程序使用 HTTP 重定向强制用户跳转到专用页面进行身份验证。
例如，如果用户尝试访问 https://my.intranet.app 但缺少必要的会话 Cookie，Web 应用程序将通过 HTTP 302 重定向响应到身份验证终结点，例如 https://my.intranet.app/auth。
一旦用户在该页面上成功进行身份验证，浏览器将重定向回原始应用程序 URL，此时包含所需的身份验证 Cookie。
基于页面内表单的身份验证 [Preview]
此方法将用户保留在预期的应用程序 URL 上，同时动态呈现登录界面。
例如，如果用户导航到受保护的页面，例如 https://my.intranet.app，页面会直接加载身份验证表单，而不会触发重定向，因为缺少必要的 Cookie。此过程可能涉及页面界面与身份提供程序 (IDP) 之间的多次内部交换。这些交换会一直持续，直到提供并使用最终的有效 Cookie，从而授予用户访问原始页面内容的权限。
注意：
如果您的场景不属于上述机制涵盖的范围，并且无法将您的 Web 应用程序设置为使用上述机制，请联系 Citrix 产品团队。
配置说明
步骤 0: 简介
有两种方法可以使用 BCR 配置单点登录。选择哪种配置方法取决于所需 BCR 网站的身份验证机制以及您为单点登录支持配置多个 Web 应用程序所需的灵活性。
方法 1： 此方法使用 Web Studio 中现有的 BCR 策略，并利用它们来实现单点登录支持。
在引入单点登录支持之前，浏览器内容重定向身份验证站点策略用于指定用于身份验证（或中间页面）的 URL，这些 URL 将重定向到客户端，以确保流程不中断。
随着单点登录支持的引入，BCR 将利用 VDA 侧浏览器上的身份验证 Cookie，因此，身份验证站点策略中的 URL 现在需要配置在浏览器内容重定向阻止列表策略中。这可确保身份验证通过 VDA 进行。
方法 2： 此方法的操作逻辑与方法 1 类似，但 URL 是通过 JSON (bcrconfig.json) 配置的，并且托管的 JSON URL 在 BCR ACL 策略中调用。JSON 配置提供了额外的灵活性。
- 企业在其环境中使用了多个 Web 应用程序，每个应用程序可能根据其实现使用不同的身份验证机制。新的 JSON 方法使配置更加直观、强大和可扩展。
- 在处理基于页面内表单的身份验证时，方法 1 无法提供设置特定身份验证 Cookie 的方法，因为没有现有策略支持此类配置。因此，如果您的网站需要基于页面内表单的身份验证，JSON 是唯一的方法。
展望未来，JSON 提供了一种可扩展的方式来引入更强大的功能，Citrix 建议尝试基于 JSON 的配置。
步骤 1：确定身份验证机制
要确定您的配置使用哪种方法，第一步是确定您的应用程序正在使用哪种身份验证机制。要准确确定 Web 应用程序的身份验证方法，最好的方法是联系 Web 应用程序管理员。
如果无法做到这一点，您必须在未安装 BCR 扩展的情况下执行身份验证流程时，检查浏览器开发人员工具中“网络”选项卡下的请求/响应交互。以下结果可以帮助您确定身份验证类型：
对于基于重定向的身份验证： 在“状态”列下查找一个或多个 302（重定向）响应。302 响应应包含指向身份验证页面的位置标头。如果您使用方法 1，则此页面 URL 必须在浏览器内容重定向阻止列表策略中设置；如果您使用方法 2，则此页面 URL 必须在 bcrconfig.json 文件中应用程序配置的 denyList 部分中设置。
对于基于页面内表单的身份验证： 在“方法”列下查找多个 POST 请求。POST 请求的后续响应之一应返回一个 set-cookie 标头，其中包含 Web 应用程序特定的身份验证 Cookie。此 Cookie 应在 bcrconfig.json 文件中应用程序配置的 Cookie 部分中设置。由于方法 1 不支持基于页面内表单的身份验证，因此方法 2 是此场景的唯一配置选项。
示例： 以下是 github.com 的示例。此方法可用于您希望使用 BCR 重定向并确保正确配置的任何网站
- 打开 Chrome，然后按 CTRL+SHIFT+I 调出其开发人员工具。
- 点击网络选项卡。
- 勾选保留日志设置。
- 点击文档筛选器以简化网络日志。
- 右键单击名称旁边，并添加URL列。
- 在浏览器中访问github.com，同时保持开发人员工具打开。
- 请登录到以下网站 github.com
- 记下 github.com 的初始页面与其登录后的目标页面之间发生登录后的所有中间跳转。
- 分析请求/响应标头，以确定如上所述的身份验证类型。
步骤 2: 选择配置方法
-
如果您只处理基于重定向的身份验证，并且不需要重定向具有不同需求的多个 Web 应用程序（例如，一个 Web 应用程序使用基于重定向的身份验证，另一个 Web 应用程序使用基于页面内表单的身份验证），则可以选择方法 1 来配置单点登录。
-
如果您正在处理基于页面内表单的身份验证，（或者）您正在处理具有不同身份验证机制的多个 Web 应用程序，（或者）即使您只有基于重定向的身份验证，也只是想要更大的灵活性，则可以选择方法 2。
步骤 3: 配置
方法 1: 使用现有策略配置 BCR 单点登录
- 通过在
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\HDXMediaStream key: Dword BrowserProfileSharing value 1中创建以下注册表值，在 VDA 中启用该功能 - 使用要重定向的网站配置浏览器内容重定向 ACL 配置策略。这方面无需更改配置。
- 如果您已在身份验证站点策略中配置了 URL，请将它们复制到浏览器内容重定向阻止列表策略中，并禁用身份验证站点策略。
- 如果您之前未配置身份验证/中间站点，请识别中间 URL（在未安装 BCR 扩展的情况下执行身份验证流程时，从浏览器开发人员工具的“网络”选项卡中的请求/响应交互中获取），并将它们配置到阻止列表中。
方法 2：使用 JSON 配置 BCR 单点登录
创建 bcrconfig.json 文件的方法和步骤
bcrconfig.json 可以包含多个 Web 应用程序配置。BCR 扩展将尝试将请求的 URL 与 apps 数组中某个应用程序指定的 allowList 之一进行匹配，并动态应用其相关规则来决定如何处理页面重定向和单点登录处理。以下键可用于控制 BCR 扩展如何处理 Web 应用程序（请注意，根据 JSON 规范，布尔值必须为小写 - 只能是 true 或 false）：
- appName [string value, mandatory]：这主要供扩展内部使用，并用于日志记录目的。
-
allowList [string array, mandatory]：应用程序必须在
allowList中至少包含一个 URL，该 URL 旨在被重定向，以便客户端而不是 VDA 呈现页面。可以定义多个 URL，并且接受通配符。通配符规则与 浏览器内容重定向 ACL 配置 完全相同。例如，要配置所有 Google 应用程序进行重定向，请使用以下数组：[“.google.com/”, “.google.com”, “.youtube.com”, “.youtube.com/”]
- denyList [string value, optional]：定义当需要身份验证时 Web 应用程序将用户重定向到的 URL。此配置主要对于基于重定向的身份验证至关重要，但它也可用于防止某些基于表单的身份验证流中的特定重定向。此键中列出的 URL 将不会被重定向，以便进行服务器端身份验证。当不需要配置文件共享以限制域的特定子 URL 不被重定向到客户端时，您也可以使用此功能。
- profileSharing [boolean value, mandatory]：这是需要设置的关键值，以确保单点登录身份验证 Cookie 和存储用户偏好的其他 Cookie 得到共享，从而确保服务器端和客户端呈现页面之间的一致行为。
- cookies [string array, optional]：定义 Web 应用程序加载所需的一个或多个身份验证 Cookie，而无需提示用户。然后，扩展将阻止客户端重定向，直到检测到此处列出的所有 Cookie 都已为给定的 Web 应用程序 URL 设置。此设置主要用于页面内基于表单的身份验证，但在某些情况下，除了指定 denyList 之外，它还可以用于基于重定向的身份验证。
-
deleteClientCache[boolean value, optional]：如果使用
bcrconfig.json配置机制，则 BCR 客户端默认会删除其浏览器缓存以增强安全性。此过程发生在用户关闭所有重定向的选项卡或在会话中首次启动重定向页面时。将此键的值设置为 false 以防止此行为。如果客户端设备受信任，则将此键设置为 false 可以增强用户体验。如果客户端设备不受信任，则不设置此键（或）将此键设置为 true 可以增强安全态势。 - schemaVersion [string value, mandatory]：这主要供扩展内部使用，并用于日志记录目的。在撰写本文时，其值应设置为 2511。
示例配置说明
{
"apps": [
{
"appName": "myWebApp1",
"allowList": [
"https://myWebApp1.com/*"
],
"denyList": [],
"requires": {
"profileSharing": false,
"cookies": []
}
},
{
"appName": "myWebApp2",
"allowList": [
"https://myWebApp2.com/*"
],
"denyList": [
"https://myWebApp2.com/authPortal/*"
],
"requires": {
"profileSharing": true,
"cookies": []
}
},
{
"appName": "myWebApp3",
"allowList": [
"https://*.myWebApp3.com/"
],
"denyList": [
"https://myWebApp3.com/authPortal/*"
],
"requires": {
"profileSharing": true,
"cookies": [
"requiredAuthCookie1",
"requiredAuthCookie2"
]
}
}
],
"preferences": {
"deleteClientCache": true
},
"schemaVersion": "2511"
}
<!--NeedCopy-->
以下是一个示例 bcrconfig.json 文件。其元素在下面详细解释：
上述 JSON 结构包含 3 个具有不同配置的应用程序：
myWebApp1 场景，无 单点登录:
-
allowList键的字符串数组值指定 https://myWebApp1.com 中的所有路径都应重定向到客户端，但denyList键中列出的值（如果有）除外。 -
denyList键的字符串数组值为空，因此不会阻止任何身份验证站点重定向。因此，身份验证不会严格保留在服务器端。 -
profileSharing键的布尔值设置为 false，因此与allowList条目相关的 Cookie 不会与客户端共享。 - cookies 键的字符串数组为空，但由于
profileSharing共享键设置为 false，它无论如何都会被忽略。
myWebApp2，基于重定向的身份验证场景：
-
allowList键的字符串数组值指定 https://myWebApp2.com 中的所有路径都应重定向到客户端，但denyList键中列出的值（如果有）除外。 -
denyList键的字符串数组值指定 myWebApp2.com 域下以/authPortal/开头的路径将阻止客户端重定向，以便可以执行服务器端身份验证。 -
profileSharing键的布尔值设置为 true，因此与 allowList 条目相关的 Cookie 将与客户端共享，并且单点登录将通过。 -
cookies 键的字符串数组为空，因此扩展程序不会等待在服务器端身份验证后设置特定的 Cookie，然后才与客户端共享。
myWebApp3，基于表单的身份验证场景：
-
allowList键的字符串数组值指定 https://myWebApp3.com 中的所有路径都应重定向到客户端，但denyList键中列出的值（如果有）除外。 -
denyList键的字符串数组值指定 myWebApp2.com 域下以/authPortal/开头的路径将阻止客户端重定向，以便可以执行服务器端身份验证。 -
profileSharing键的布尔值设置为 true，因此与allowList条目相关的 Cookie 将与客户端共享。 -
cookies键的字符串数组包含一个 cookie 名称，因此扩展程序将等待此 cookie 在服务器端身份验证后设置。allowList中相关 URL 的 cookie 将与客户端共享，并将发生客户端重定向。
首选项
-
deleteClientCache键设置为 true，因此 BCR 客户端默认会删除其浏览器缓存以增强安全性。即使未设置此键，这也是默认行为。
配置 BCR 策略
创建 bcrconfig.json 后，请按照以下步骤配置 浏览器内容重定向 ACL 配置 以使用 JSON 文件中的内容。
-
将文件命名为
.bcrconfig.json扩展名，例如，myrules.bcrconfig.json -
将 JSON 文件托管在 VDA 可访问的 Web 服务器上，并记下 URL。
注意：
服务器必须允许文件下载；Microsoft IIS 站点默认允许 JSON 文件下载。
-
在 Citrix Studio 的“策略”下，将上一步中的 URL 添加到“浏览器内容重定向 ACL 配置”设置中：
注意：
“浏览器内容重定向 ACL 配置”设置中的其他条目可以保留。如果发生冲突，BCR 扩展程序会优先使用
bcrconfig.json设置。Citrix 建议将整个配置转移到 JSON，以便于管理、应用程序级配置和可扩展性。 -
保存该策略，并启动一个会话以测试策略配置。
注意：
设置策略后，您可以随时编辑托管的
bcrconfig.json文件进行调整。文件仅在运行 BCR 扩展程序的主浏览器进程启动或重新启动时重新加载并应用更改。
注意：
本质上，从策略角度来看，您只需启用浏览器内容重定向策略（默认已启用），并使用指向 JSON 文件的 URL 配置浏览器内容重定向 ACL 配置策略。
JSON 配置目前适用于以下策略并使其更灵活，但其余策略仍执行与以前相同的操作。
- 浏览器内容重定向 ACL 配置：ACL 中的 URL 现在可以通过
allowList键通过 JSON 进行配置。- 浏览器内容重定向阻止列表配置：阻止列表现在可以通过
denyList键通过 JSON 进行配置。- 浏览器内容重定向身份验证站点：身份验证站点也可以通过
denyList键通过 JSON 进行配置。