产品文档
Citrix Virtual Apps and Desktops
Service Current Release 2402 LTSR 2311 2308 2305 2303 2212 2209 2206 2203 LTSR 1912 LTSR
查看 PDF

单点登录支持

April 8, 2026
投稿者: 
C

简介

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

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

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

  • 未启用单点登录

  • 在 BCR 中打开已通过身份验证的页面时，用户每次都需要重新输入凭据，从而破坏了 SSO 持久性。
  • SSO 仅在 BCR 窗口保持打开状态时才得以维持；关闭并重新打开窗口会强制用户重复登录过程。

  • 身份验证流发生在客户端，这会强制管理员从客户端设备向安全的身份验证站点提供网络访问。

  • 启用单点登录后

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

最低要求

  • Citrix Virtual Apps and Desktops 2511
  • 适用于 Windows 2511 的 Citrix Workspace 应用程序
  • 适用于 Linux 2511 的 Citrix Workspace 应用程序 (预览版)
  • 浏览器重定向扩展 (Chrome 或 Edge) 25.11 或更高版本

支持的身份验证序列

BCR 单点登录目前支持两种类型的身份验证序列。

基于重定向的身份验证

在此标准方法中，应用程序使用 HTTP 重定向强制用户访问专用于身份验证的页面。

例如，如果用户尝试访问 https://my.intranet.app 但没有必要的会话 Cookie，则 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 配置提供了额外的灵活性。

  1. 企业在其环境中使用了多个 Web 应用程序，每个应用程序可能根据其实现使用不同的身份验证机制。新的 JSON 方法使配置更加直观、健壮和可扩展。
  2. 在处理基于页面内表单的身份验证时，方法 1 不提供设置特定身份验证 Cookie 的方式，因为没有现有策略支持此类配置。因此，如果您的网站需要基于页面内表单的身份验证，JSON 是唯一的方法。

  • 展望未来，JSON 提供了一种可扩展的方式来引入更强大的功能，Citrix 建议尝试基于 JSON 的配置。

  • 步骤 1：确定身份验证机制

  • 要确定您的配置应使用哪种方法，第一步是确定您的应用程序正在使用哪种身份验证机制。要准确确定 Web 应用程序的身份验证方法，最佳方法是联系 Web 应用程序管理员。

  • 如果无法做到这一点，您必须在未安装 BCR 扩展的情况下执行身份验证流程时，检查浏览器的开发人员工具中“网络”选项卡下的请求/响应交互。以下结果可以帮助您确定身份验证类型：

对于基于重定向的身份验证： 在“状态”列下查找一个或多个 302（重定向）响应。302 响应应包含指向身份验证页面的位置标头。如果您使用方法 1，则必须在浏览器内容重定向阻止列表策略中设置此页面 URL；如果您使用方法 2，则在 bcrconfig.json 文件中应用程序配置的 denyList 部分中设置。

对于基于页面内表单的身份验证： 在“方法”列下查找多个 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 键中创建以下注册表值来在 VDA 中启用此功能：Dword BrowserProfileSharing 值 1
  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 [字符串值，必需]：这主要供扩展内部使用和用于日志记录。

  • allowList [字符串数组，必需]：应用程序的 allowList 中必须至少包含一个 URL，该 URL 旨在被重定向，以便客户端而不是 VDA 呈现页面。可以定义多个 URL，并且接受通配符。通配符规则与 浏览器内容重定向 ACL 配置 完全相同。例如，要配置所有 Google 应用程序以进行重定向，请使用以下数组：

    [“*.google.com/*”, “*.google.com”, “*.youtube.com”, “*.youtube.com/*”]

  • denyList [字符串值，可选]：定义当需要身份验证时 Web 应用程序将用户重定向到的 URL。此配置主要对于基于重定向的身份验证至关重要，但它也可以用于防止某些基于表单的身份验证流程中的特定重定向。此键中列出的 URL 将不会被重定向，以便进行服务器端身份验证。当不需要配置文件共享时，您也可以使用此功能来限制域的特定子 URL 不被重定向到客户端。

  • profileSharing [布尔值，必需]：这是需要设置的关键值，以确保单点登录身份验证 Cookie 和存储用户偏好的其他 Cookie 得到共享，从而确保服务器端和客户端呈现的页面之间行为一致。

  • cookies [字符串数组，可选]：定义一个或多个身份验证 Cookie，这些 Cookie 对于 Web 应用程序在不提示用户的情况下加载是必需的。扩展将阻止客户端重定向，直到检测到此处列出的所有 Cookie 都已为给定 Web 应用 URL 设置。此设置主要用于基于页内表单的身份验证，但在某些情况下，除了指定拒绝列表 (denyList) 之外，它还可以用于基于重定向的身份验证。
  • deleteClientCache [布尔值，可选]：如果使用 bcrconfig.json 配置机制，则 BCR 客户端默认会删除其浏览器缓存以增强安全性。当用户关闭所有重定向的选项卡或在会话中首次启动重定向页面时，会发生此过程。将此键的值设置为 false 可阻止此行为。如果客户端设备受信任，则将此键设置为 false 可以增强用户体验。如果客户端设备不受信任，则不设置此键（或）将此键设置为 true 可以增强安全态势。
  • schemaVersion [字符串值，强制]：这主要供扩展内部使用，并用于日志记录。在撰写本文时，其值应设置为 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 键的字符串数组值指定 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 进行配置。
单点登录支持
April 8, 2026
投稿者: 
C
April 8, 2026
投稿者: 
C

在本文中

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