3. 用户、组与目录管理

在 Atlassian 平台（Jira、Confluence、Bitbucket 等）中，权限治理的起点不是权限方案本身，而是“谁是谁、谁属于谁、谁从哪里来”。用户、组与目录三者构成了权限体系的身份底座：目录决定账号来源与认证方式，用户是权限授予的最小主体，组则是批量授权与继承的载体。理解这三者的关系，才能避免“权限看起来配了却没人能访问”或“离职人员仍能登录”这类典型问题。

一、目录：账号的来源与优先级

Atlassian Cloud 与 Data Center 在目录模型上差异明显。Cloud 站点通常包含两类目录：Atlassian 账户目录（本地托管用户，由 Atlassian 管理）和外部目录（通过 SAML SSO 或 SCIM 接入的身份提供商，如 Okta、Azure AD、Google Workspace）。Data Center 则通过 User Directories 配置多个目录，如内部目录、LDAP、Crowd、Jira Internal Directory 等，并可为每个目录设置目录顺序（Directory Order）。

目录顺序直接决定身份解析结果：当同一用户名或邮箱在多个目录中存在时，系统按顺序从上到下匹配，命中即停止。因此实践中应遵循两条原则：外部权威目录排在本地目录之前，避免本地同名账号“遮蔽”外部账号；本地目录仅保留服务账号或应急管理员，不承载普通员工身份。若顺序颠倒，常见症状是用户通过 SSO 登录后仍被识别为本地账号，导致组同步失效、权限不生效。

二、本地用户与组：最小可用身份模型

本地用户适用于无法接入外部目录的场景，例如小型团队、外部协作方、临时账号。创建本地用户时需关注三个字段：用户名（登录标识，通常不可改）、邮箱（通知与找回入口）、显示名（界面展示）。本地用户默认不参与 SSO，若站点已启用强制 SSO，需为其单独配置例外策略，否则会被登录策略拦截。

组是权限继承的核心单元。Atlassian 中组分为两类：平台级组（如 jira-administrators、confluence-users、site-admins）和自定义组（如 dev-team、qa-team）。平台级组往往绑定全局权限，不应随意将普通用户加入；自定义组则用于项目角色映射与空间权限授予。组可以嵌套，但嵌套层级过深会显著增加权限排查难度，建议控制在两层以内。

三、外部目录同步与 SCIM

外部目录同步解决的是“身份数据一致性”问题。仅配置 SAML SSO 只能完成认证（Authentication），用户仍需手动创建或首次登录时即时创建（JIT Provisioning），且用户离职后账号不会自动停用。SCIM（System for Cross-domain Identity Management）则补齐了授权（Provisioning）环节：IdP 作为权威源，通过 SCIM 协议将用户的创建、更新、停用、组关系变更实时推送到 Atlassian。

SCIM 同步的关键对象是 User 与 Group。典型配置流程如下：在 IdP 侧创建 SCIM 应用，生成 Bearer Token；在 Atlassian 管理后台启用 User Provisioning，填入 Token 与 SCIM Base URL；随后在 IdP 侧分配用户与组到该应用。同步触发方式分为实时推送（用户变更立即同步）与定时全量对账（通常每日一次），两者应同时启用，以修复推送丢失导致的漂移。

需要特别注意的是组映射规则：IdP 中的组名推送到 Atlassian 后，默认按原名创建。若 IdP 组名与 Atlassian 既有组名不一致，会产生重复组，导致权限授予落空。建议在 IdP 侧统一命名规范，例如 atlassian-jira-admins、atlassian-confluence-users，并在启用前用测试组验证映射结果。

四、用户生命周期管理

用户生命周期可归纳为五个状态：创建、激活、变更、停用、删除。每个状态都对应明确的治理动作与判断依据。

• 创建：优先由 SCIM 自动创建；本地创建仅用于例外场景，需记录申请人与用途。
• 激活：用户首次登录或接受邀请后进入可用状态。若启用 SCIM，激活由 IdP 分配应用触发。
• 变更：包括改名、换组、角色调整。SCIM 环境下组变更由 IdP 推送；本地环境下需人工调整组关系。
• 停用：离职或长期离岗时，应在 IdP 侧停用账号，SCIM 会将其同步为 Atlassian 的“已停用”状态。停用用户无法登录，但其历史操作记录与权限授予关系仍保留，便于审计。
• 删除：仅在确认无需保留审计痕迹时执行。删除用户会解除其组关系，但不会自动清理其创建的内容。Atlassian Cloud 中删除用户会释放许可证席位，但需注意“匿名化”与“完全删除”的区别。

五、权限继承关系与排查方法

Atlassian 的权限继承遵循“组 → 角色 → 权限方案 → 资源”的链路。以 Jira 为例：用户加入组 → 组被授予项目角色（如 Administrators、Developers）→ 项目角色在权限方案中被赋予具体权限（如 Administer Projects、Browse Projects）→ 权限方案绑定到项目。Confluence 类似：用户加入组 → 组被授予空间权限 → 空间权限决定页面操作能力。

当出现“用户无法访问”时，可按以下顺序排查：

1. 确认用户当前所在目录与账号状态（是否停用、是否被本地同名账号遮蔽）。
2. 确认用户所属组，以及该组是否被正确映射到目标项目角色或空间权限。
3. 确认权限方案中该角色是否包含所需权限，以及是否存在更严格的全局权限覆盖。
4. 确认用户是否受到 IP 允许列表、SSO 强制策略或双因素认证策略的限制。

为提升排查效率，建议维护一份“组—角色—权限方案”对照表，并在每次权限方案变更后更新。下表为一个简化示例：

最后需要强调：目录顺序、SCIM 同步状态与组映射规则是三个最容易出错的环节。建议在正式启用 SCIM 前，先用一个测试组完成“创建—加入组—授予权限—停用—确认权限回收”的完整闭环验证，确认无误后再逐步扩大同步范围。身份底座稳固，后续的权限方案与空间治理才有可靠的基础。