在大多数情况下，Cloudflare Access 和企业身份提供商之间的技术集成只需不到一个小时 - 交换元数据、一些 URL、身份验证测试。接下来要做的事情需要数周时间：决定哪些组可以访问哪些应用程序、会话时长、MFA 要求以及如何处理不同 IdP 上的外部协作者。协议配置是文档细节。策略架构是设计决策。
SAML、OIDC 以及选择时的注意事项
Cloudflare Access 支持 SAML 2.0 和 OIDC。对于大型企业提供商（Okta、Azure AD、Google Workspace、OneLogin、Ping Identity、JumpCloud），Cloudflare 维护具有精确字段映射的集成指南。 SAML 和 OIDC 之间的选择很少是一个关键的技术决策；两者对于访问身份验证用例的作用是等效的。
实际的区别在于，OIDC 对于现代提供商来说配置更简单，并且直接返回 JWT 格式的属性。 SAML 需要 XML 断言格式的属性映射，这会增加更复杂的配置中的摩擦 — 特别是当您想要从 IdP 传递自定义属性以在策略中使用时。对于与 Okta 或 Azure AD 的新集成，OIDC 是阻力最小的路径。
同时多个身份提供商
在初始项目中未被注意到的访问功能：同一组织可以配置多个提供程序并将不同的提供程序分配给不同的应用程序。应用程序接受员工通过 Google Workspace 进行身份验证，以及外部协作者通过 GitHub 接受身份验证。另一种仅限于 Okta 公司。第三个显示选择菜单，供用户选择要使用的提供商。
这解决了公司员工分布在不同合作伙伴公司、每个公司都有自己的 Azure AD 或 Google Workspace 的常见情况。 Access 不是在所有提供商上创建来宾帐户，而是接受多个提供商，每个提供商具有不同的策略。实际限制不是技术上的，而是管理上的：每个额外的提供程序都是一个需要维护的配置点和一个需要监控的访问向量。
群组和授权同步
引用组在身份验证时直接从 IdP 提取成员身份的访问策略。 “允许：组工程”策略不是 Cloudflare 中的静态列表 - 它是在身份验证令牌到达时针对 Okta 或 Azure AD 中的组进行的检查。当在 IdP 上的组中添加或删除协作者时，下一次身份验证会立即生效，无需在 Cloudflare 平台上手动同步。
这具有重要的操作后果：卸载过程需要将用户从 IdP 中删除，而不仅仅是撤销每个单独应用程序中的访问权限。如果用户在 Okta 中停用，则依赖于该 IdP 的所有访问策略将停止对该帐户起作用。活动会话在过期之前保持有效，这强调了为每个应用程序配置适当的会话持续时间的重要性。
每个应用程序的会话持续时间和 MFA 执行
会话持续时间是在 Access 中按应用程序配置的，而不是全局配置的。对于低灵敏度室内监控应用，7 天是合理的。对于生产环境的 SSH 访问，一个小时的会话需要频繁的重新身份验证，从而减少了令牌受损的窗口。对于数据库管理小组来说，15 分钟可能更合适。
无论 IdP 做什么，访问级别都可能需要 MFA。如果 IdP 默认情况下不强制执行 MFA，则访问策略可能需要使用第二因素身份验证 - 如果令牌不包含此保证，Access 将重定向用户以在 IdP 处完成 MFA。不同的应用可以有不同的认证保障需求，而无需在IdP上配置多个MFA策略。
用于机器对机器访问的服务令牌
CI/CD 管道、监控代理、Webhook — 任何需要访问受访问保护的资源的自动化系统都会面临一个问题：没有人类用户来执行 SSO 流程。 Access 通过服务令牌解决了这个问题：将服务标识为可信实体的客户端 ID 和客户端密钥对。
自动化服务包括标头 0 中的客户端 ID 和11 中的秘密。 Access 会识别服务令牌，评估关联的策略，并允许或拒绝访问 - 与任何其他访问一样生成审核事件。服务令牌具有可配置的到期日期，并且可以单独撤销，而不会影响其他令牌或用户。
如何在调用之前构建策略
采用 Access 时最常见的设计错误是在没有层次结构模型的情况下创建每个应用程序的策略。对于数十个内部应用程序，为每个应用程序维护单独的策略将成为一项相当大的运营负担。另一种方法是定义可重用的访问组——“所有员工的基本访问权限”、“工程团队的提升访问权限”、“SRE 的管理访问权限”——并将它们作为每个应用程序的单独策略中的块应用。
新应用程序的访问策略可以继承基本组并添加特定条件，例如强制设备姿势或时间限制。当工程团队规模扩大并在 IdP 中创建新组时，Access 中的可重用组策略更新会自动传播到引用它的所有应用程序。
配置前需要决定什么
与 IdP 的技术集成是最小的挑战。最重要的一项是在生产中启用 Access 之前记录政策决策及其基本原理。哪些应用程序可供所有员工自动访问？哪些需要明确的团体批准？合作公司的外部员工受到怎样的待遇？谁让 IdP 中的组与访问策略保持一致？
这些问题没有技术答案——它们是安全团队和产品团队需要共同做出的决定。在没有回答这些问题的情况下进行技术设置的团队通常会得到非常宽松的策略，这些策略通过顶部的身份验证层来复制 VPN 问题。
另请阅读
- [Cloudflare 零信任：无需 VPN 即可访问内部应用程序2
- [Cloudflare Access 与 Tunnel：哪个在零信任中执行什么操作3?
- [WARP：Cloudflare 的零信任客户端及其真正用途4
- [零信任 vs VPN：变革的真正成本5