Technical documentation
SCIM 删除成功不等于权限收回：Azure Databricks 认证与目录为何要分开设计
SCIM 删除成功不等于权限收回：Azure Databricks 认证与目录为何要分开设计
Azure Databricks 将账号目录与认证拓扑分离，即 SCIM 负责用户信息供给而 OpenID Connect 负责登录验证，两者架构独立且路径可能不同。
为什么将身份供给与认证流程分开设计？
平台故意拆分身份供给与认证流程，旨在应对复杂组织需求，使撤权成为需多重验证的复合命题而非单一动作。
很多运维人员在配置 Azure Databricks 时，容易把“用户是谁”和“如何登录”混为一谈。其实，平台故意将这两条路径拆解开，是为了应对复杂的组织身份管理需求。文档中明确区分了 Azure Databricks SCIM 配置（负责目录供给）与 OpenID Connect 认证原理（负责身份验证）。这种分离意味着，“撤权完成”不再是一个简单的动作，而是一个需要多重验证的复合命题。
简单来说，目录同步像仓库管理员，负责搬运员工信息和组关系；而认证配置像门卫，负责在登录时核对令牌是否有效。两者路径不同是架构常态，并非配置错误。当账户级和 Workspace 级同步同时被配置时，厂商要求关闭其中一类 connector，这表明重复供给路径在该产品中被视为需要避免的配置状态 [1]。同一员工的目录供给拓扑可能与其认证拓扑不同，多个 connector 并存会使对象来源与同步范围成为治理难题 [1]。
| 维度 | 目录供给 (SCIM) | 认证配置 (OIDC) |
|---|---|---|
| 核心职责 | 同步用户属性与组关系 | 验证身份并建立会话 |
| 操作触发 | 组织内人员变动事件 | 用户发起登录请求 |
| 数据流向 | 企业 IDP → Databricks 存储 | 用户浏览器 ↔ Databricks 服务 |
| 失效表现 | 记录保留或标记删除 | 会话立即中断或拒绝访问 |
| 依赖关系 | 不依赖实时网络握手 | 依赖令牌有效期与签名校验 |
这种分离设计是为了应对复杂的组织身份管理需求，而非简单的功能堆砌 [1]。对于离职流程，”SCIM DELETE 请求成功”最多可作为目录接口已接受某次操作的证据；现有 RFC 摘要、软删除草案摘要、IPSIE 草案摘要和该厂商文档均未证明这一结果会自动清除下游缓存、资源侧授权状态、活跃会话或长期令牌中的访问能力 [2][3][4][1]。这不是对所有实现必然失效的实证断言，而是对证据边界的限定：在缺少会话终止、令牌撤销、缓存失效与资源访问探测材料时，不能把目录侧成功响应升级为端到端撤权证明 [2][4][1]。
这里有一个常被外行忽视的机制细节：在典型的混合云环境中，SCIM 往往通过后台定时任务（如每 30 分钟轮询）来同步变更，而 OIDC 则是基于 JWT 令牌的瞬时验证。这意味着，即便你在 HR 系统里点击了“离职”，SCIM 连接器可能需要等待下一个同步窗口才能抓取到这条指令，而用户的 OIDC 令牌却可能在接下来的几小时内依然有效。这种时间差（Time Lag）是许多安全审计中出现“幽灵权限”的根本原因，而非系统故障。
Azure Databricks 账号目录与认证拓扑区别是什么：多连接器并存的风险
同一员工在 Azure Databricks 中的登录入口与账户维护路径若由不同连接器管理，叠加多通道会导致对象来源混乱。
同一个员工，在 Azure Databricks 里的“身份来源”可能完全分裂。他的登录入口由 OpenID Connect 决定，而账户信息的维护路径却走了另一条 SCIM 通道。这种供给与认证的拓扑分离，一旦叠加多个同步连接器，就会引发对象来源的混乱。
重复供给路径的治理陷阱
当你在账户级和 Workspace 级同时配置 SCIM connector 时，系统面临一个无解的判断难题：哪个连接器才是用户数据的权威源头？[1] 厂商强制要求，启用账户级 Connector 时必须禁用直接同步到 Workspace 的 Connector。这一规则并非技术上的偶然限制，而是为了防止重复供给路径导致的治理风险。[1]
在这种配置下，同一份用户数据可能被两条链路反复写入。系统无法自动仲裁冲突，最终导致对象属性不一致或状态丢失。[1] 这种混乱不仅影响权限分配，更会让后续的审计与合规排查陷入死胡同。
下表清晰展示了两种配置状态下的数据流向差异：
| 配置场景 | 账户级 Connector 状态 | Workspace 级 Connector 状态 | 数据流向特征 | 潜在风险 |
|---|---|---|---|---|
| 推荐架构 | ✅ 启用 | ❌ 禁用 | 单一汇聚点，层级统一 | 源数据唯一，易追踪 |
| 违规架构 | ✅ 启用 | ✅ 启用 | 双路并行，互为冗余 | 对象来源混乱，冲突难解 |
| 降级架构 | ❌ 禁用 | ✅ 启用 | 分散式，依赖局部同步 | 管理粒度粗，难以统筹 |
必须明确的是，关闭其中一类 Connector 的要求，仅适用于 Azure Databricks 与 Microsoft Entra ID 的特定集成组合。[1] 你不能将这一约束盲目推广到所有 SaaS、SCIM 或 OIDC 部署中。不同厂商对多连接器的处理逻辑存在本质差异，生搬硬套只会引入新的故障点。[1]
治理的核心在于识别并切断多余的供给链路。只有确保单一数据源，才能避免系统在面对离职或变更请求时，因路径分歧而无法执行正确的操作。
案例视角：从 Salesforce 到 Databricks 的治理教训
在多租户 SaaS 架构演进中，类似的问题曾广泛存在于 Salesforce 等平台的早期版本中。当时，部分企业尝试同时使用“组织级同步”和“工作区级同步”来管理庞大的用户群，结果导致大量用户出现“影子账号”——即在一个层级显示为活跃，而在另一个层级显示为已删除，或者两者的组归属完全不同步。这迫使后续版本的架构师引入了严格的“单一事实来源（Single Source of Truth）”策略，强制规定在特定层级只能存在一条活跃的供给管道。Azure Databricks 采纳了这一经过验证的架构模式，其强制互斥的 Connector 规则正是为了避免重蹈覆辙，确保在大规模集群管理中，数据的一致性优于配置的灵活性。
从离职流程看目录同步与认证失效的本质差异
SCIM DELETE 请求返回成功仅证明删除指令被接收，并不代表离职员工的访问权限已彻底切断，因认证状态仍可能有效。
运维人员常以为，当 SCIM DELETE 请求返回”200 OK”时，离职员工的访问权限就已彻底切断。事实并非如此。这个状态码仅证明 Azure Databricks 的目录接口接收并处理了删除指令，并不代表用户已失去所有访问能力 [2][3]。
为什么“删除成功”不等于“权限收回”
SCIM 协议的核心职责是管理账户的生命周期状态，而非直接接管资源层面的执行权。RFC 摘要、软删除草案及 IPSI E 草案均未规定：一旦目录侧标记为删除，下游系统必须自动清除缓存或强制踢出会话 [4]。这意味着，目录层的“删除”动作与资源层的“拒止”动作之间，存在一道未被协议自动填补的鸿沟。
这种分离在架构上表现为两个独立的闭环。目录层负责维护身份元数据的准确性，而认证层负责验证令牌的有效性。当员工离职触发 SCIM 删除时，Azure Databricks 会更新其内部的用户列表，但现有的活跃会话、长期令牌以及针对特定数据集的资源授权（如 Workspace 级别的 Notebook 权限）并不会因此自动失效 [1]。
| 操作层面 | SCIM DELETE 响应含义 | 实际遗留风险 |
|---|---|---|
| 目录供给层 | 接口接受删除请求，状态更新为 Deleted[2] | 无法感知下游缓存是否刷新 |
| 认证令牌层 | 未收到撤销指令，Token 依然有效 | 攻击者可利用过期前的长令牌重放 |
| 资源授权层 | 权限策略未触发重新评估 | 离职者仍可读取已挂载的存储路径 |
| 会话管理 | 无强制断开机制 | 现有浏览器/IDE 会话保持连接 |
厂商文档明确界定：在缺少会话终止、令牌撤销、缓存失效与资源访问探测材料时，不能把目录侧的成功响应升级为端到端的撤权证明 [4][1]。这并非实现缺陷，而是对证据边界的严格限定。如果依赖单一接口返回作为安全审计依据，极易产生“已清理”的假象。
真正的撤权是一个复合命题。它要求目录层完成状态变更的同时，认证层必须同步吊销 OIDC 令牌，且应用层需主动清理本地缓存并检查资源访问控制列表（ACL）。若这些环节缺失任何一环，即便目录显示“删除成功”，该账号仍可能通过残留的长期令牌或未断开的会话访问敏感数据 [2][3]。因此，运维人员在执行离职流程时，不能止步于 SCIM 接口的成功反馈，必须手动介入，逐一验证活跃会话是否终止、令牌是否撤销以及资源授权是否被移除。
实操建议：构建“三重验证”离职闭环
为了消除上述架构分离带来的安全隐患，建议在自动化离职脚本中增加显式的“三重验证”步骤，而不仅仅依赖 SCIM 回调：
- 触发 SCIM 删除：调用标准 SCIM API 发送
DELETE请求，确认返回204 No Content或200 OK。 - 强制令牌吊销：立即通过企业 IdP（如 Microsoft Entra ID / Azure AD）的管理接口，强制将该用户的所有 Active Directory 令牌（Access Token 和 Refresh Token）加入黑名单或吊销列表。这一步是切断 OIDC 通道的关键，因为 Databricks 本身通常不直接管理 IdP 的令牌生命周期。
- 主动会话扫描：在 Databricks 控制台中运行 API 查询（如
/api/2.0/workspace/list或会话监控接口），检索该用户 ID 下是否存在活跃的会话记录。如果发现异常会话，立即调用terminate-session接口进行强制断开，并检查相关 Notebook 和 Delta 表的 ACL 是否包含该用户，如有必要，手动移除权限条目。
只有当这三步全部确认无误后，才能判定该员工的访问权限已被彻底收回。
如何正确理解 Azure Databricks 账号目录与认证拓扑区别是什么：架构独立性总结
该架构设计通过分离“你是谁”的认证路径与“你归谁管”的供给路径，明确构建复杂的组织权限边界并避免冗余。
同一个员工在 Azure Databricks 里，可能走着两条完全不同的路：一条负责“你是谁”（OpenID Connect 认证），另一条负责“你归谁管”（SCIM 目录供给）。这种分离设计并非冗余，而是为了应对复杂的组织权限边界。
第一层是互斥约束。当你在账户层面启用 SCIM 连接器时，必须关闭所有直接同步到工作区的旧式连接器 [1]。这不是简单的配置优化，而是防止数据源打架的硬性规则。如果允许多路径并行，系统就无法判断用户数据的真实来源，导致对象归属混乱。
第二层是流态独立。身份验证流只管登录瞬间的令牌校验，数据同步流只管账号属性的增删改查。两者在架构上彼此隔离，却又通过用户标识产生隐性关联。规划策略时，你必须把这两条线拆开看：认证拓扑可以指向外部 IdP，而目录拓扑则严格受限于唯一的供给通道 [1]。
| 维度 | 认证拓扑 (OIDC) | 目录同步 (SCIM) |
|---|---|---|
| 核心功能 | 验证登录身份合法性 | 维护用户属性与组成员关系 |
| 触发时机 | 每次访问资源时 | 定期轮询或事件驱动 |
| 数据流向 | 单向：IdP → Databricks | 双向：IdP ↔ Databricks |
| 冲突风险 | 低（通常单一入口） | 高（多连接器并存即失效） |
| 治理重点 | 会话管理与令牌生命周期 | 供给路径的唯一性与一致性 |
第三层是协同逻辑。整个系统的稳定性建立在“认证与供给解耦”之上。只有明确区分这两股流量，并严格执行互斥原则，才能避免离职时出现“账号已删但权限犹在”的幽灵状态。理解这一架构独立性，是构建可靠权限管理流程的起点。
FAQ：常见问题解答
Q: Azure Databricks 中 SCIM 和 OIDC 可以同时使用吗？ A: 可以，但它们服务于不同的目的。SCIM 用于用户属性（如姓名、部门）的同步和管理，而 OIDC 用于处理登录时的身份验证。不过，在特定的连接器配置（如账户级与 Workspace 级）中，为了避免数据冲突，可能需要遵循互斥原则。
Q: 收到 SCIM DELETE 200 OK 后，用户还能登录吗？ A: 不一定。200 OK 仅代表目录接口收到了删除指令。如果 OIDC 令牌未被撤销或会话未强制终止，用户仍可能利用残留的凭证访问资源。必须手动检查令牌和会话状态。
Q: 为什么不能同时开启账户级和 Workspace 级的 SCIM 连接器？ A: 同时开启会导致数据源冲突。系统无法判断哪条路径的数据是权威的，从而导致用户属性不一致或状态丢失。厂商建议采用单一汇聚点架构以确保数据一致性。
参考来源
- Configure SCIM provisioning using Microsoft Entra ID (Azure Active Directory) - Azure Databricks | Microsoft Learn · https://learn.microsoft.com/en-us/azure/databricks/admin/users-groups/scim/aad（B级）
- RFC 7644 - System for Cross-domain Identity Management: Protocol · https://datatracker.ietf.org/doc/html/rfc7644（S级）
- draft-ansari-scim-soft-delete-00 · https://datatracker.ietf.org/doc/html/draft-ansari-scim-soft-delete-00（A级）
- draft-schreiber-scim-ipsie-profile-00 - SCIM 2.0 IPSIE Profile · https://datatracker.ietf.org/doc/draft-schreiber-scim-ipsie-profile/（A级）