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

单点登录支持

September 3, 2026
投稿者: 
C

简介

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

此增强功能消除了冗余登录，通过在 BCR 会话中（即使在 BCR 窗口关闭后）保持身份验证和 Cookie 持久性来提高工作效率。

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

无单点登录

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

有单点登录

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

最低要求

  • Citrix 虚拟应用和桌面 2507
  • 适用于 Windows 的 Citrix Workspace 应用程序 2511
  • 适用于 Linux 的 Citrix Workspace 应用程序 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部分中设置。

对于基于页面内表单的身份验证： 在“方法”列下查找多个POST请求。POST请求的后续响应之一应返回一个带有Web应用程序特定身份验证Cookie的set-cookie标头。此Cookie应在bcrconfig.json文件中的应用程序配置的cookies部分中设置。由于方法1不支持基于页面内表单的身份验证，因此方法2是此场景的唯一配置选项。

示例： 这是一个github.com的示例。此方法可用于您希望通过BCR重定向并确保正确配置的任何网站。

  1. 打开 Chrome，然后按 CTRL+SHIFT+I 以调出其开发者工具。
  2. 点击“网络”选项卡。
  3. 勾选“保留日志”设置。
  4. 点击“Doc”筛选器以简化网络日志。
  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

该 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 进行配置。
单点登录支持
September 3, 2026
投稿者: 
C
September 3, 2026
投稿者: 
C

在本文中

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