—— 当系统越来越多，OA 迟早要变成“身份总开关”
很多公司最开始的 OA 就是：请假、报销、用章、公告。
但一旦你开始加东西：
- AI 助手（Dify / 自研网关）
- 工作流引擎（Flowable）
- 媒体平台（MediaCMS）
- 门户、知识库、数据平台……
你会很快遇到一个非常朴素的痛点：
系统越多，登录越乱；权限越多，解释不清；出了问题，追责追不到。
这时候你才发现：用户系统不是“登录按钮”，它是企业数字化的“总电闸”。
1. 什么时候必须搞统一登录？
一句话判断：
当你有 3 个以上系统，且它们会“互相调用”或“共享数据”，你就必须统一。
典型现象：
- 员工抱怨：怎么又要登录？
- 管理员崩溃：每个系统都要建人、调部门、配权限
- AI 答得离谱：财务制度谁都能查，涉密资料也能问出来
- 出事了追不动：不知道是谁用哪个系统干了啥
到这里，别犹豫——你要做的不是“再写一个登录页”，而是：
统一身份 + 统一登录 + 统一权限口径 + 统一审计。
2. 先把“主数据在哪”讲清楚：用户到底归谁管？
不要一上来就讨论 Keycloak / Casdoor。先回答一个更现实的问题：
新员工入职时，谁来创建账号？离职时，谁来禁用？调岗时，谁来改部门？
谁负责这些，谁就是用户主数据源（权威源）。
一般有三种做法：
做法 A：OA 继续当“人员系统”（最常见、最省事）
- OA 里有人、组织架构、部门、职级
- 其他系统别各自维护人
适合：中小企业、内网为主、团队小、要快上线。
做法 B：上独立身份中心（Keycloak / Casdoor 等）
- 身份中心管登录协议、MFA、账号安全、审计
- OA 负责“人员信息和管理界面”
- 身份中心从 OA 同步用户或对接 LDAP/AD
适合：系统越来越多、开始对外、合规要求更强。
做法 C：混合（大厂常见）
- OA / HR 系统是“人事真相”
- IdP 是“登录真相”
- 权限另有权限中心/策略中心
你现在最实用的路线通常是：
先 A 跑起来，等你真被安全/审计/多系统搞痛了，再上 B。
3. 统一登录到底做什么？别把它想复杂
统一登录（SSO）说白了就是一件事：
用户在公司只登录一次，后面的系统都认这个“通行证”。
这个“通行证”通常就是一个 Token（例如 JWT），但重点不是“JWT 这三个字”，重点是：
- 谁签发（统一的签发方）
- 谁能用（aud/客户端）
- 用多久（过期时间）
- 能不能撤销（离职/封号）
- 能不能查账（审计）
推荐选型：OIDC（内部系统首选）
你可以把 OIDC 理解成：
“标准化的企业登录协议”，浏览器登录、API 调用都能用。
SAML 也能做 SSO，但更像“兼容老企业系统”的方案。
4. 真实落地：最建议的“接地气架构”
结合你提到的 OA + Dify + Flowable + MediaCMS，最实用的形态通常是：
用户只认 OA 登录（或 IdP）
|
(OIDC/SSO)
|
┌──────────────┐
│ Gateway │ ← 你自己/统一接入层（强烈建议）
│ 鉴权 + 审计 + │
│ 用户上下文注入 │
└───────┬────────┘
|
┌────────┼─────────────┐
│ │ │
Dify Flowable MediaCMS
为什么要 Gateway？因为现实世界很残酷：
- 有的系统 OIDC 支持不完整
- 有的系统权限模型很粗
- AI 的权限控制通常要你自己做“检索过滤”
- 审计要集中，否则查日志查到怀疑人生
Gateway 就是你把这些坑集中填平的地方。
5. “用户上下文”才是关键：SSO 不是为了少输密码
统一登录只解决“省事”，真正要解决的是“能控”。
你需要让系统知道：
- 你是谁（user_id）
- 你属于谁（部门/组织）
- 你是什么角色（roles）
- 你能看什么范围（data scope）
- 你来自哪个系统（client_id）
- 这次登录是什么时候（auth_time）
一个接地气的 Token Claims 可以这样：
{
"sub": "u_12345",
"name": "lucas",
"dept_id": "d_it",
"roles": ["it_admin"],
"tenant": "companyA",
"client_id": "oa-web",
"exp": 1730000000
}
但注意一句非常重要的工程经验：
Token 里放“身份 + 粗粒度角色”就够了，细粒度权限别全写死。
因为权限会变，你不可能等 token 过期才能生效。
6. Dify（AI）要接入身份，怎么做才靠谱？
很多人以为：把 roles 放进 prompt 就行。
这在企业里是不够的，原因很现实：
- Prompt 约束不等于数据访问控制
- 你必须在“检索层/数据层”就把不该给的数据挡住
接地气的做法通常是：
用户请求先到 Gateway
Gateway 校验 token，拿到用户上下文
-
Gateway 决定：
- 允许查哪些知识库（按部门/密级）
- 检索时带上 metadata filter（比如 dept_id / doc_level）
Dify 负责编排与生成，但不是权限裁判
一句话：
AI 的权限控制要落在检索与数据访问层，不要指望 LLM 自觉。
7. Flowable（流程）怎么接入用户体系？
流程引擎非常依赖“谁能审批、谁属于哪个组织”。
现实最稳的做法：
- OA 是用户主库（人、组织、岗位）
- Flowable 不做主库
- Flowable 只保留必要映射（或通过接口查询 OA）
不要让流程引擎变成第二个“人事系统”。
否则你会遇到：OA 调岗了，Flowable 还没调，审批直接乱套。
8. MediaCMS（媒体）接统一身份有什么好处？
媒体系统最容易出现“权限失控”：
- 本来只想让宣传部看，结果全公司都能下载
- 某个视频被外传，你不知道是谁下的
接入统一身份后，你至少能做到：
- 访问权限和 OA 一致（部门、角色）
- 谁看了、谁下了，都能审计
- 离职禁用一次，全系统失效
9. 最现实的演进路线（不折腾版本）
别一上来就“平台化 IAM”。按阶段交付，最稳：
Phase 1：先把“统一登录”跑起来
- 选 OIDC
- 要么 OA 发 token
- 要么上 Keycloak/Casdoor 发 token（更省心）
交付标准：用户只登录一次，多系统都能用。
Phase 2：统一用户上下文（Claims 口径一致）
-
sub/dept_id/roles/tenant/client_id标准化 - Gateway 负责注入/透传
交付标准：各系统都能拿到同一套用户信息，不再各写各的。
Phase 3：权限开始统一（从“角色”走向“数据范围”）
- 菜单权限用 RBAC
- 数据访问用 ABAC/策略（至少网关回查）
交付标准：同一个角色在不同系统的“能看范围”一致。
Phase 4：你真的痛了，再把身份中心平台化
- MFA、密码策略、风控、审计、Key rotation
- 这些最好交给专业 IdP
10. 最常见的坑（全是血泪）
- 每个系统自己登录：最后一定乱
- Token 没有统一签发方：系统之间谁也不信谁
- 权限全塞进 token：权限变更无法即时生效
- AI 不做检索过滤：迟早越权泄露
- 没有统一审计：出了事查不出来
总结一句话
当你把 Dify、Flowable、MediaCMS 这类系统接进来后，OA 的定位必然变化：
OA 不再只是流程系统，它会逐渐成为企业“身份与权限”的总入口。
最接地气的路线就是：
- 先统一登录（OIDC）
- 再统一用户上下文（Claims）
- 权限控制落在 Gateway/检索/数据层
- 真的需要时再上独立 IdP
