带集成 SSO 的应用程序

过去几年中，许多组织认识到了单一事实来源身份的重要性，并将他们的 SSO 提供程序直接与内部应用程序集成。SSO 提供程序仅感知应用程序所在的内部域名（通过配置的 ACS URL），这意味着用户必须连接到本地网络才能访问该应用程序。这种安全架构对于传统的网络边界是有意义的，但它给 Zero Trust 的采用带来了挑战。在无代理访问模型中，用户的设备没有内部企业网络的概念，只有他们有权访问的具体且被作用域限定的应用程序。该问题在下图中进行了总结：

flowchart LR
accTitle: 带集成 SSO 的授权流程
A("用户访问
app.public.com")-->B("Cloudflare Tunnel
将公共主机名 (app.public.com)
路由到内部域名 (app.internal.com)")-->C("app.internal.com
重定向到集成 SSO")-->D("SSO ACS URL 返回
app.internal.com")-->E("404 错误
设备无法解析
app.internal.com")

潜在解决方案

如果你的应用程序使用了集成 SSO，你可以采取多种不同的途径将应用程序入组到 Cloudflare Access。

解决方案	所需步骤	优点	缺点
专在 Cloudflare 域名上呈送应用程序	将 SSO ACS URL 更改为 Cloudflare Tunnel 公共主机名	提升安全姿态无需修改应用程序代码无需修改内部 DNS 设计	当 ACS URL 从内部域名更改为外部域名时的硬切换事件
在现有内部域名上呈送应用程序，并将相同的外部域名委托给 Cloudflare	向 Cloudflare 添加与内部域名匹配的域名	无需修改 SSO ACS URL 最终用户无感知变更	需要仔细管理内部和外部域名需要更改内部 DNS 设计
在内部应用程序中消耗 Cloudflare JWT	移除集成 SSO 更新应用程序以接受 Cloudflare JWT 进行用户授权	减轻最终用户的身份验证负担无需修改内部 DNS 设计无需直接 SSO 集成即可即时保护应用程序	需要修改应用程序代码应用程序更新时的硬切换事件
使用 Cloudflare 作为直接 SSO 集成，然后调用你选择的 IdP（Okta、OneLogin 等）	将现有 SSO 提供商替换为 Access for SaaS	增加更改 IdP 的灵活性能够同时使用多个 IdP	IdP 变更时的硬切换事件应用程序没有 SCIM 预配

推荐解决方案

如果你能够配置 SSO 提供商，我们建议专门在 Cloudflare 域名上呈送所有内部 Web 服务。这是 Cloudflare 在内部采用的 Web 应用程序访问模型，也是此场景中客户最常用的解析方法。

采用这种方法，你不需要对现有的 DNS 基础设施做出任何更改。你的网络中的 Cloudflare Tunnel 将管理从外部（Cloudflare 公共）DNS 到内部 DNS 的转换，这就是该系统的设计运行方式。在你将 SSO 提供商中的 ACS URL 更新为 Cloudflare 公共主机名后，结果将如下所示：

flowchart LR
accTitle: 更新 SSO ACS URL 后的授权流程
A("用户访问
app.public.com")-->B("Cloudflare Tunnel
将公共主机名 (app.public.com)
路由到内部域名 (app.internal.com)")-->C("app.internal.com
重定向到集成 SSO")-->D("SSO ACS URL 返回
app.public.com")-->E("浏览器显示 app.public.com")

所有用户——无论是在办公室、远程、使用还是不使用 VPN 客户端——在访问私有应用程序时都将始终通过位于 app.public.com 的 Cloudflare Access 身份验证流程。这为策略应用和安全审计提供了单一控制平面，并且不需要额外的用户培训。