单点登录支持
简介
浏览器内容重定向现在提供简化的用户体验，支持单点登录，实现VDA端身份验证和Cookie共享。
此增强功能消除了重复登录，通过在BCR会话中保持身份验证和Cookie持久性（即使在BCR窗口关闭后），从而提高了生产力。
这种无缝体验通过确保身份验证源自VDA而非客户端，进一步增强了安全性。
无单点登录
-
在BCR中打开已验证页面时，要求用户每次重新输入其凭据，从而破坏了SSO持久性。
-
SSO仅在BCR窗口保持打开状态时才得以维持；关闭并重新打开窗口会强制用户重复登录过程。
-
身份验证流程发生在客户端，迫使管理员从客户端设备提供对安全身份验证站点的网络访问权限。
使用单点登录
-
用户不再需要输入凭据（当已在VDA上进行身份验证时），因为SSO会从VDA浏览器无缝保留。
-
身份验证发生在VDA端，这通过限制客户端网络要求和暴露来提高安全态势，从而提供显著改进且不间断的体验。
最低要求
-
思杰虚拟应用和桌面 2507
-
思杰工作区应用程序适用于 Windows 2511
-
思杰工作区应用程序适用于 Linux 2601
-
浏览器重定向扩展 (Chrome 或 Edge) 25.11 或更高版本
支持的身份验证序列
目前有两种类型的身份验证序列支持 BCR 单点登录。
基于重定向的身份验证
在这种标准方法中，应用程序使用 HTTP 重定向强制用户跳转到专门的身份验证页面。
例如，如果用户尝试在没有必要的会话 cookie 的情况下访问
<https://my.intranet.app>，Web 应用程序将以 HTTP 302 重定向响应到身份验证端点，例如 <https://my.intranet.app/auth>。
一旦用户在该页面成功进行身份验证，浏览器将重定向回原始应用程序 URL，现在包含所需的身份验证 Cookie。
页面内基于表单的身份验证
此方法将用户保留在预期的应用程序 URL 上，同时动态呈现登录界面。
例如，如果用户导航到受保护的页面（例如
<https://my.intranet.app>），页面会直接加载身份验证表单而不会触发重定向，因为缺少必要的 cookie。此过程可能涉及页面界面和身份提供程序 (IDP) 之间的多次内部交换。这些交换会一直持续，直到提供并使用最终的有效 cookie，从而授予用户访问原始页面内容的权限。
注意：
如果您的场景不属于上述机制涵盖的范围，并且无法设置您的 Web 应用程序以使用上述机制，请联系 Citrix 产品团队。
配置
步骤 0：简介
有两种方法可以配置 BCR 单点登录。选择配置方法取决于所需 BCR 网站的身份验证机制以及您为单点登录支持配置多个 Web 应用程序所需的灵活性。
**方法 1：**此方法使用 Web Studio 中现有的 BCR 策略并利用它们实现单点登录支持。
在引入单点登录支持之前，浏览器内容重定向身份验证站点策略用于指定用于身份验证（或中间页面）的 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，则必须在
bcrconfig.json 文件中的应用程序配置的 denyList 部分中设置此页面 URL。
对于基于页面内表单的身份验证： 在“方法”列下查找多个 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）：
示例配置
{
"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"
}
这是一个示例
bcrconfig.json 文件。其元素在下面详细解释：
上述 JSON 结构包含 3 个具有不同配置的应用程序：
myWebApp1 场景，无 SSO：
-
allowList键的字符串数组值指定<https://myWebApp1.com>中的所有路径都应重定向到客户端，除非denyList键中列出了值（如果有）。 -
denyList键的字符串数组值为空，因此不会阻止任何身份验证站点进行重定向。因此，身份验证将不会严格保留在服务器端。 -
The
profileSharing键的布尔值设置为 false，因此与allowList条目相关的 cookie 不会与客户端共享。 -
cookies 键的字符串数组为空，但由于
profileSharing共享键设置为 false，它无论如何都会被忽略。
myWebApp2，基于重定向的身份验证场景：
-
allowList键的字符串数组值指定<https://myWebApp2.com>中的所有路径都应重定向到客户端，除非denyList键中列出了值（如果有）。 -
The
denyList键的字符串数组值指定 myWebApp2.com 域下以/authPortal/开头的路径将阻止客户端重定向，以便执行服务器端身份验证。 -
The
profileSharing键的布尔值设置为 true，因此与 allowList 条目相关的 cookie 将与客户端共享，并且单点登录将通过。 -
cookies 键的字符串数组为空，因此扩展程序不会等待在服务器端身份验证后设置特定 cookie，然后才将其与客户端共享。
myWebApp3，基于表单的身份验证场景：
-
allowList键的字符串数组值指定<https://myWebApp3.com>中的所有路径都应重定向到客户端，除非denyList键中列出了值（如果有）。 -
The
denyList键的字符串数组值指定 myWebApp3.com 域下以/authPortal/开头的路径将阻止客户端重定向，以便执行服务器端身份验证。 -
The
profileSharing键的布尔值设置为 true，因此与allowList条目相关的 cookie 将与客户端共享。 -
cookies 键的字符串数组包含一个 cookie 名称，因此扩展程序将等待在服务器端身份验证后设置此 cookie。
allowList中相关 URL 的 cookie 将与客户端共享，并发生客户端重定向。
首选项
-
The
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 进行配置。
-