产品文档
Citrix Virtual Apps and Desktops
服务 当前版本 2607 LTSR 2511 2507 LTSR 2503 2411 2407 2402 LTSR 2311 2203 LTSR
查看 PDF

单点登录支持

August 28, 2026
投稿者: 
C

简介

浏览器内容重定向现在提供简化的用户体验，支持单点登录，并启用 VDA 侧身份验证和 Cookie 共享。

此增强功能消除了重复登录，通过在 BCR 会话中（即使在 BCR 窗口关闭后）保持身份验证和 Cookie 持久性来提高生产力。

这种无缝体验通过确保身份验证源自 VDA 而非客户端，进一步增强了安全性。

未启用单点登录时

  • 在 BCR 中打开已验证页面时，用户每次都需要重新输入凭据，从而破坏了 SSO 持久性。
  • SSO 仅在 BCR 窗口保持打开状态时才有效；关闭并重新打开窗口会强制用户重复登录过程。
  • 身份验证流程发生在客户端，迫使管理员从客户端设备向安全的身份验证站点提供网络访问。

启用单点登录后

  • 用户不再需要输入凭据（当已在 VDA 上进行身份验证时），因为 SSO 已从 VDA 浏览器无缝保留。
  • 身份验证发生在 VDA 上，通过限制客户端网络要求和暴露来提高安全态势，从而提供显著改进且不间断的体验。

最低要求

  • Citrix 虚拟应用和桌面 2507
  • 适用于 Windows 的 Citrix Workspace 应用程序 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 配置提供了额外的灵活性。

  1. 企业在其环境中使用了多个 Web 应用程序，每个应用程序可能根据其实现方式使用不同的身份验证机制。新的 JSON 方法使配置更直观、更强大、更具可扩展性。
  2. 在处理基于页面内表单的身份验证时，方法 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 重定向的任何网站，并确保您具有正确的配置

  1. 打开 Chrome，然后按 CTRL+SHIFT+I 调出其开发人员工具。
  2. 点击网络选项卡。
  3. 勾选保留日志设置。
  4. 点击文档筛选器以简化网络日志。
  5. 右键单击名称旁边并添加URL列。
  6. 在浏览器中访问github.com，同时保持开发人员工具打开。
  7. 登录github.com
  8. 记下 github.com 的初始页面与其登录后的目标页面之间发生的所有中间跳转。
  9. 分析请求/响应标头以确定如上所述的身份验证类型。

步骤 2: 选择配置方法

  1. 如果您只处理基于重定向的身份验证，并且不需要重定向具有不同需求的多个 Web 应用程序（例如，一个 Web 应用程序使用基于重定向的身份验证，另一个 Web 应用程序使用基于页面内表单的身份验证），则可以选择方法 1 来配置单点登录。

  2. 如果您正在处理基于页面内表单的身份验证，(或者) 您正在处理具有不同身份验证机制的多个 Web 应用程序，(或者) 即使您只有基于重定向的身份验证，也只是想要更大的灵活性，则可以选择方法 2。

步骤 3: 配置

方法 1: 使用现有策略配置 BCR 单点登录

  1. 通过在 HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\HDXMediaStream key: Dword BrowserProfileSharing value 1 中创建以下注册表值，在 VDA 中启用该功能
  2. 使用要重定向的网站配置浏览器内容重定向 ACL 配置策略。这方面无需更改配置。
  3. 如果您已在身份验证站点策略中配置了 URL，请将其复制到浏览器内容重定向阻止列表策略中，并禁用身份验证站点策略。
  4. 如果您之前未配置身份验证/中间站点，请识别中间 URL（在未安装 BCR 扩展的情况下执行身份验证流程时，从浏览器开发人员工具的“网络”选项卡中的请求/响应交互中获取），并将其配置到阻止列表中。

方法 2：使用 JSON 配置 BCR 单点登录

创建 bcrconfig.json

The 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 场景，无 SSO：

  • 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 扩展程序的主浏览器进程启动或重新启动时才会重新加载并应用更改。

注意：

  • 从策略角度来看，本质上，您只需启用浏览器内容重定向策略（该策略默认启用），并配置浏览器内容重定向 ACL 配置策略，使用指向 JSON 文件的 URL。

  • JSON 配置目前适用于以下策略并使其更灵活，但其余策略仍执行与以前相同的操作。

    • 浏览器内容重定向 ACL 配置： ACL 中的 URL 现在可以通过 allowList 键通过 JSON 进行配置。
    • 浏览器内容重定向阻止列表配置： 阻止列表现在可以通过 denyList 键通过 JSON 进行配置。
    • 浏览器内容重定向身份验证站点： 身份验证站点也可以通过 denyList 键通过 JSON 进行配置。
单点登录支持
August 28, 2026
投稿者: 
C
August 28, 2026
投稿者: 
C

在本文中

站点反馈 | Your privacy choices footer link您的隐私选择 | 隐私和法律条款 | Cookie 首选项 | 同意设置 | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.