KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

01 · 它到底解决了什么问题 — keel 龙骨

## 现场：五个系统，五套账号

现场：五个系统，五套账号

一家公司里，你要登录的东西往往不止一个，而是一排：

邮件系统 · 工单系统 · 报表后台 · 代码仓库 · 报销系统

五个系统，就是五套账号。新同事入职，要挨个开五个；有人离职，要挨个跑五个后台去停号；
每个系统的密码规则还不一样，于是大家干脆五个都设成同一个，或者写在便利贴上贴在显示器边。

到这一步，问题已经不是"密码太难记"了。真正的问题是：
"同一个人"这件事，被拆成了五份，散在五个地方，五个地方彼此不认识。

公司想统一处理"这个人是谁、他能不能进"，却没有一个地方能给出这个答案。

一、没有它的世界长什么样

把上面那句展开，你会看到三类具体的坏处：

1. 身份对不上。 邮件系统里的"张三"和工单系统里的"zhangsan"是不是同一个人？
   没人能给一个权威答案——因为两边各存了一份，谁也不是权威。
2. 重复劳动。 开一个号是五遍，改一次密码是五遍，停一个号还是五遍。
   多一个系统，工作量就再乘一遍。
3. 信任无处安放。 报表后台凭什么相信"现在坐在这里的人是张三"？
   它只能再收一次密码——于是密码又多存了一份，又多了一个可能泄露的地方。

这三条合起来是一句话：每个系统都在自己做"证明你是谁"这件事，而这活本该只做一次。

二、SSO 做了什么

SSO（Single Sign-On，单点登录）的做法是：把"证明你是谁"从每个系统里抽出来，
交给一个专门的角色统一做；各个系统不再自己收密码，只负责相信它给出的结论。

先认识三个词，后面每一章都会用到：

现在先看这个"专门角色"公开在什么地方。每个 IdP 都会把"我是谁、该去哪登录、该去哪换凭证"
公布在一个固定网址上：

curl -s http://localhost:8081/realms/master/.well-known/openid-configuration | head -c 300

前置：这条命令要有一个 IdP 正在跑。第 2 章会用一条 docker 命令把它起起来——
你可以先读完第 2 章把容器起好，再回到这里敲这一条。

你会看到一段 JSON，形状是这样（只截了开头）：

{"issuer":"http://localhost:8081/realms/master",
 "authorization_endpoint":"http://localhost:8081/realms/master/protocol/openid-connect/auth",
 "token_endpoint":"http://localhost:8081/realms/master/protocol/openid-connect/token", ...

地址里的 master 是 Keycloak 自带的一个圈（realm），第 2 章起来就有；
你自己那个装应用的圈到第 3 章才建。endpoint 是"端点"——
可以理解成"这栋楼里不同的窗口"。数字和网址随你的环境变，要读的是形状：
一个 issuer 加一串 …_endpoint。

这张清单就是那句话的兑现：一个 IdP，一个固定网址，五个 SP 只需要认这一个网址。
以后要加第六个系统，新增的那一个也只需要看这张清单。

三、它不是什么

SSO 这个词容易让人想大，先把两条边界划清：

• 不是权限系统。 SSO 回答的是"你是谁"，它不回答"你能干什么"。
  一个员工登录成功，进报表后台能看到哪几张表、能不能导出——这是授权，是另一件事，
  另一门课（权限与多租户的
  00 章）专门讲。
  SSO 只管把人认出来，然后把"他是谁"告诉系统。
• 不是账号治理。 它不负责"入职审批该谁点、离职流程几天内走完、僵尸账号怎么定期清理"。
  SSO 把"在哪存账号"统一了，但流程和规矩仍然要人来定。
  反过来，没有 SSO 也不等于做不了账号治理——只是每做一次都要在五个地方各做一遍。

一句话记法：SSO 管"认人"，不管"定规矩"，也不管"发许可"。

读完你能做什么

• 用一句话说清 SSO 解决的是"同一个人要在多个系统间被认成同一个人"；
• 说出 IdP、SP、断言三个词各指什么，并能各举一个能看见的形态；
• 说清 SSO 不管什么（权限、账号治理）——这是这一章最想留下的判断。

下一步：现在你知道它是什么了。下一章把它跑起来——
用一条 docker 命令起一个真实的 IdP，亲眼看到那句启动成功的日志。

进入 keel 阅读