单点登录支持
引言部分
浏览器内容重定向现在通过单点登录支持提供简化的用户体验，从而实现 VDA 侧身份验证和 Cookie 共享。
此增强功能消除了冗余登录，通过在 BCR 会话中（即使在 BCR 窗口关闭后）保持身份验证和 Cookie 持久性来提高工作效率。
这种无缝体验通过确保身份验证源自 VDA 而非客户端，进一步增强了安全性。
没有单点登录
- 在 BCR 中打开已验证页面时，用户每次都需要重新输入凭据，从而破坏了 SSO 的持久性。
- SSO 仅在 BCR 窗口保持打开状态时才得以维持；关闭并重新打开窗口会强制用户重复登录过程。
- 身份验证流程发生在客户端，这迫使管理员从客户端设备向安全的身份验证站点提供网络访问。
使用单点登录
- 用户不再需要输入凭据（如果已在 VDA 上进行身份验证），因为 SSO 已从 VDA 浏览器无缝保留。
- 身份验证发生在 VDA 端，这通过限制客户端网络要求和暴露来改善安全状况，从而提供显著改进且不间断的体验。
最低系统要求
- Citrix 虚拟应用和桌面 2507
- 适用于 Windows 的 思杰 工作区应用程序 2511
- Citrix Workspace 应用程序，专门用于 Linux 操作系统，版本号为 2601
- 浏览器重定向扩展（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，则必须在bcrconfig.json文件中的应用程序配置的denyList部分中设置。
对于基于页面内表单的身份验证： 在“方法”列下查找多个POST请求。POST请求的后续响应之一应返回一个带有Web应用程序特定身份验证cookie的set-cookie标头。此cookie应在bcrconfig.json文件中的应用程序配置的cookie部分中设置。由于方法1不支持基于页面内表单的身份验证，因此方法2是此场景的唯一配置选项。
示例： 这是一个github.com的示例。此方法可用于您希望通过BCR重定向并确保正确配置的任何网站。
- 打开 Chrome，然后按 CTRL+SHIFT+I 调出其开发者工具。
- 单击网络选项卡。
- 勾选保留日志设置。
- 单击Doc筛选器以简化网络日志。
- 右键单击名称旁边，然后添加URL列。
- 浏览到 github.com，同时保持开发人员工具打开。
- Sign in to 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 单点登录
Creating 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]：定义一个或多个身份验证 Cookie，这些 Cookie 对于 Web 应用程序在不提示用户的情况下加载是必需的。然后，扩展将阻止客户端重定向，直到检测到此处列出的所有 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键的字符串数组值指定 myWebApp3.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 现在可以通过 JSON 经由
allowList键进行配置。- 浏览器内容重定向阻止列表配置： 阻止列表现在可以通过 JSON 经由
denyList键进行配置。- 浏览器内容重定向身份验证站点： 身份验证站点也可以通过 JSON 经由
denyList键进行配置。