第一部分：IDaaS 基础 on IDaaS Book

IAM 是什么：身份与访问管理入门 | IDaaS Book

Thu, 09 Jul 2026 00:00:00 +0800

IAM 是什么

IAM（Identity and Access Management，身份与访问管理）是一套管理「谁可以访问什么」的能力体系，而不是某一个具体产品。它涵盖四个核心域：

如果只记一个判断：IAM 不是“登录中心”，而是身份状态、访问决策和权限回收的控制面。登录只是认证入口；一个可上线的 IAM 还必须说明身份由谁负责、授权在哪里执行，以及离职或风险变化后权限如何收敛。

认证（Authentication）：确认你是谁——密码、MFA、生物特征、Passkey
授权（Authorization）：确认你能做什么——RBAC、ABAC、PBAC
用户管理（User Management）：账号的生命周期——创建、变更、禁用、删除
审计（Audit）：记录谁在什么时候做了什么——合规、追溯、异常检测

这里要区分能力域和规范要求：NIST SP 800-63B-4 约束的是远程用户认证及认证保证等级（AAL），并不替企业定义完整的 IAM 产品边界；SCIM RFC 7644 则规定跨系统管理用户资源的 HTTP 接口语义，也不等于权限决策或 Token 撤销。把这些边界写进架构设计，能避免把“登录成功”误当成“访问已授权”。

简单理解：IAM 就是企业的「门禁系统和访客登记簿」的结合体——它决定谁能进哪个门，进去后能做什么，并记录一切出入痕迹。

为什么需要 IAM

没有 IAM 的世界

每个应用自己管账号 → 100 个应用 = 100 套账号密码
员工离职 → IT 需要逐个应用禁用账号，漏一个就是安全漏洞
审计问「谁在什么时候访问了什么」→ 需要翻 100 个系统的日志
权限管理混乱 → 不该看到数据的人看到了，该看到的人没权限

有了 IAM 的世界

统一身份：一个账号，所有应用通行
集中管控：启用/禁用从一个地方发起，并能追踪下游收敛状态
完整审计：所有身份操作一目了然
自动化：入职自动创建账号分配权限，离职自动回收

IAM 的核心能力

身份生命周期不是“禁用账号”这么简单

很多 IAM 介绍把离职流程写成“调用一次禁用接口”。生产环境里真正要验证的是权限是否在下游收敛：身份源标记离职后，IAM 应停止新的登录和令牌签发；通过 SCIM 对接的应用还要完成禁用或删除；已经发出的 Access Token 则要按其有效期、撤销机制或网关在线校验策略处理，不能把“SCIM 返回 200”当成访问已经消失。OAuth 2.0 Token Revocation（ RFC 7009）规定的是客户端向授权服务器请求撤销凭证的接口语义，不会替资源服务器自动抹除已经缓存的授权结果。

第1章：什么是 IDaaS — 定义、演进与企业身份即服务的核心价值 | IDaaS Book

Mon, 01 Jan 2024 00:00:00 +0800

1.1 定义

IDaaS（Identity as a Service，身份即服务）是将身份管理能力以云服务形式交付的一种架构模式。它涵盖了用户身份的创建、维护、认证、授权和审计的全生命周期管理，通过标准化的 API 和协议向应用系统提供统一的身份服务。

Gartner 将 IDaaS 定义为：“通过云端交付的、综合性的身份和访问管理服务，包括身份治理与管理（IGA）、访问管理（AM）和特权访问管理（PAM）等功能。”

从技术角度看，IDaaS 解决的是这样一个核心问题：在一个应用数量爆炸、部署环境异构的世界里，如何让正确的人，在正确的时间，以正确的方式，访问正确的资源？

1.2 为什么需要 IDaaS

1.2.1 传统 IAM 的困境

在 IDaaS 出现之前，企业通常采用本地部署的 IAM 系统。这些系统存在以下痛点：

部署周期长：从采购硬件、安装软件到配置集成，动辄数月。
维护成本高：需要专业的 IAM 工程师持续运维，升级频繁且风险高。
扩展困难：当业务快速增长或需要接入新应用时，传统 IAM 的扩展能力捉襟见肘。
集成复杂：每个应用都有自己的用户系统和认证方式，形成了大量的身份孤岛。
安全风险集中：自建的 IAM 系统一旦被攻破，所有接入应用都将面临风险。

1.2.2 数字化转型的推动

以下趋势催生了 IDaaS 的快速发展：

SaaS 应用爆发：企业平均使用超过 100 个 SaaS 应用，每个应用都需要独立的身份管理。
多云和混合云：应用分布在多个云平台和数据中心，需要统一的身份层。
远程办公常态化：员工从任何地点、任何设备访问企业资源，安全边界消失。
零信任安全架构：从"信任但验证"转向"永不信任，始终验证"。
合规要求加严：GDPR、个人信息保护法等对身份数据的管理提出了更高要求。

1.2.3 IDaaS 的核心价值

价值维度	传统 IAM	IDaaS
部署时间	3-12 个月	数天到数周
运维成本	高（需专职团队）	低（服务商承担）
可扩展性	受限于硬件	弹性伸缩
协议支持	有限，更新慢	持续更新，紧跟标准
集成生态	需定制开发	预置数千连接器
安全更新	手动打补丁	自动更新
高可用	自建灾备	多区域 SLA 保障

1.3 IDaaS 的演进历程

第一阶段：目录服务时代（1990s-2000s）

以 Microsoft Active Directory 和 LDAP 目录服务为代表。这个阶段的身份管理主要是"企业内部的员工账号管理"，认证协议以 Kerberos、NTLM 为主，目录访问以 LDAP 为主。身份管理的范畴局限于企业内网，外部用户和合作伙伴的身份管理极其有限。

IAM 和 IDaaS 区别——从架构到选型，一页讲清楚 | IDaaS Book

Sun, 12 Jul 2026 00:00:00 +0800

IAM 和 IDaaS 是什么关系

先说结论：IDaaS 是 IAM 的一种交付形态，不是 IAM 的替代品。就像「云数据库」和「数据库」的关系——云数据库还是数据库，只是跑在别人机房、按量付费。

用一句话区分：

IAM：身份与访问管理这个能力域本身（不管跑在哪、谁运维）
IDaaS：把 IAM 能力做成云服务，你只管用，运维和升级由厂商负责

拉一张对比表会更清楚：

维度	IAM（自建）	IDaaS（云服务）
部署位置	自己的数据中心或私有云	SaaS 厂商的云基础设施
运维责任	你的团队：升级、扩容、备份、安全加固	厂商：SLA 保障，你只需要配置
初始成本	高——硬件、部署、人员培训	低——按月/按用户付费，开箱即用
定制灵活度	完全可控，源码级定制	受限于厂商 API 和配置选项
数据主权	数据 100% 在你手里	数据在厂商基础设施上，需评估合规
典型玩家	Keycloak、Apereo CAS、Dex（自建部署）	Okta/Auth0、Microsoft Entra ID、自建 Keycloak 也被视为私有 IDaaS
适合谁	合规要求极高、定制需求深、有专业运维团队	希望快速上线、不想养 IAM 运维团队的中小团队

关于 IAM 的完整定义和四大核心域（认证、授权、用户管理、审计），见 IAM 是什么；IDaaS 的起源和部署模式，见什么是 IDaaS。

从演进角度看区别

IAM 和 IDaaS 的边界不是一成不变的，它们沿这条线演变：


 graph LR
 A["2000s<br/>传统 IAM<br/>(自建机房)"] -->|"云化"| B["2015s<br/>IDaaS 1.0<br/>(托管 SSO/MFA)"]
 B -->|"能力下沉"| C["2020s<br/>混合 IAM<br/>(自建+IDaaS 联邦)"]
 C -->|"边缘+零信任"| D["现在<br/>分布式身份<br/>(IDaaS 为控制面)"]

传统 IAM 时代：Microsoft AD + ADFS 是标配，身份管理绑在 Windows 域控上
IDaaS 1.0：Okta 带火了「SSO as a Service」，企业发现单点登录可以不开 AD
混合 IAM：自建 Keycloak 做核心身份 + Okta/Entra ID 做外部 B2B 联邦，各取所长
分布式身份：零信任架构下，IDaaS 从「登录入口」变成「持续验证的控制面」

所以你问「IAM 和 IDaaS 区别」时，实际上是在问：你的身份基础设施应该跑在谁的地盘上，以及谁能帮你管到什么程度。

第2章：IAM 核心理念 — AAA 模型、设计原则与身份架构 | IDaaS Book

Tue, 02 Jan 2024 00:00:00 +0800

2.1 IAM 的定义与范畴

IAM（Identity and Access Management，身份与访问管理）是信息安全领域的基础性学科，涵盖确保"正确的个体在正确的时间以正确的原因访问正确的资源"所需的所有策略、流程和技术。

IAM 的四大核心要素：

身份（Identity）：谁在请求访问？人、设备、服务还是应用？
认证（Authentication）：如何证明你是你声称的那个人？
授权（Authorization）：你能做什么？能访问什么资源？
审计（Audit）：谁在什么时候做了什么？

认证通过也不等于所有操作都应放行：高风险操作还可能要求更近的认证时间或更强的认证等级（Step-Up Authentication）。这也是 IAM 与零信任架构衔接的关键，详见零信任 IAM 架构。

2.2 身份：数字世界的通行证

2.2.1 什么是数字身份

数字身份是一组与实体（人、设备、服务）关联的属性集合，用于在信息系统中唯一标识和描述该实体。

一个典型的用户数字身份包含：

标识符（Identifier）：用户名、邮箱、手机号、员工编号
属性（Attributes）：姓名、部门、职位、角色、组成员关系
凭证（Credentials）：密码哈希、证书、生物特征模板
元数据（Metadata）：创建时间、最后登录时间、账户状态

2.2.2 身份的类型

在 IAM 系统中，身份并非只有"人类用户"一种类型：

身份类型	示例	特征
员工身份	全职/兼职员工	由 HR 系统驱动，有组织归属
合作伙伴身份	供应商、顾问	外部组织成员，访问权限受限
客户身份	终端用户	大规模，CIAM 场景。详见 CIAM vs Workforce IAM
服务身份	API 调用、微服务	无人工交互，机器身份
设备身份	IoT 设备、移动设备	设备指纹、证书认证
临时身份	访客、实习生	有时间限制，权限最小化

2.2.3 身份存储：目录服务

身份数据需要持久化存储。常见的存储方式：

LDAP 目录：树状结构，读取性能优异，写入性能一般。适合员工身份存储。

第3章：IAM 认证与授权深度辨析 — AuthN vs AuthZ 的核心区别与设计原则 | IDaaS Book

Wed, 03 Jan 2024 00:00:00 +0800

3.1 一个经典的误解

“我已经登录了，为什么还不能访问这个页面？”

这是 IAM 工程师最常听到的问题之一。在企业 IAM（身份与访问管理）体系中，用户将"能够登录"等同于"能访问所有功能"，这恰恰混淆了认证和授权的本质区别。理解这一区别是 IAM 系统设计的第一课——如果你不知道 AuthN 和 AuthZ 的分界线在哪里，你的 IAM 架构从一开始就埋下了安全债务。关于 IAM 整体框架，推荐先阅读 IAM 基础概念。

让我们用机场的比喻来理解：

认证：出示身份证件，证明"我是张三"
授权：出示登机牌，证明"我被允许乘坐CA1234航班"
有身份证（已认证）但没有登机牌（未授权），你上不了飞机
有登机牌（已授权）但没有身份证（未认证），你同样上不了飞机

3.2 认证（Authentication，AuthN）

3.2.1 认证的核心问题

认证回答三个递进的问题：

这个用户存在吗？（身份识别）
这个用户是他声称的那个人吗？（身份验证）
当前是否已经验证过？（会话管理）

3.2.2 认证方式分类

基于知识的认证

用户知道什么。

静态密码：最传统的方式，问题在于用户喜欢弱密码、复用密码、写密码在便签上。
安全问题：你第一个宠物的名字？这类问题的答案往往比密码更容易被猜中或通过社交工程获取。
图片密码：选择正确的图片组合，在移动端有一定应用场景。

基于持有的认证

用户拥有什么。

短信/邮箱验证码：最普及，但短信验证码存在 SS7 协议攻击与 SIM 劫持（SIM-swap）风险，NIST SP 800-63B 与 OWASP 均已不再将其作为强认证因素，新项目建议优先 TOTP、推送或 Passkey。
硬件 Token：U-Key、YubiKey。物理设备，安全性高，但有丢失风险和分发的物流成本。
软件 Token：TOTP（Google Authenticator、Authy）或推送通知认证。
智能卡：带有芯片的卡片，常见于大型企业和政府机构。

基于固有的认证

用户是什么。

指纹识别：方便，但指纹可以被复制，且皮肤状态影响识别率。
面部识别：Apple Face ID 是标杆实现，普通摄像头的安全性存疑。
虹膜识别：精度极高但设备昂贵。
声纹识别：可远程使用，但录音回放和 AI 合成构成威胁。
行为生物识别：击键模式、鼠标轨迹、持手机的角度。无感知认证，正在快速发展。

3.2.3 认证的技术实现

基于 Session 的认证

1. 用户提交用户名和密码
2. 服务端验证通过，创建 Session，返回 Session ID（Cookie）
3. 后续请求携带 Cookie，服务端查找 Session 验证

特点：有状态，服务端存储 Session；可即时吊销；扩展困难（Session 同步）。

第4章：身份生命周期管理 — 从创建到注销的全流程治理 | IDaaS Book

Thu, 04 Jan 2024 00:00:00 +0800

4.1 身份生命周期的阶段

每个数字身份都会经历从诞生到终结的完整旅程：

 创建 ──→ 管理 ──→ 变更 ──→ 注销
 │ │ │ │
 │ │ │ └── 永久删除或归档
 │ │ └─────────── 角色变更、部门调动
 │ └──────────────────── 权限调整、密码重置
 └───────────────────────────── 入职、注册

阶段一：身份创建（Provisioning）

新身份的产生通常由以下事件触发：

员工入职：HR 系统中创建新员工记录 → 自动创建 IAM 账户
新用户注册：用户自助注册（CIAM 场景）
合作伙伴入驻：外部组织成员获得访问权限
服务账户创建：新应用或微服务需要机器身份

创建过程的关键要素：

身份源（Identity Source）：谁说了算？HR 系统、CRM、AD、手动？
身份映射：源系统的字段如何映射到目标系统的属性？
初始权限：新身份应该有什么权限？（最小权限原则）
通知机制：如何告知用户账号信息和首次登录方式？

阶段二：身份认证与使用（Authentication & Usage）

这是用户日常与 IAM 系统交互的阶段。用户使用凭证进行认证，IAM 系统根据策略授予相应的访问权限。具体的认证和授权机制在前两章已有详细讨论。

阶段三：身份变更（Identity Modification）

身份在存续期间会经历各种变更：

属性变更

姓名变更（结婚、法律改名）
邮箱变更
手机号变更
职位、部门、上级变更

权限变更

调岗导致的权限变更
晋升导致的权限增加
项目参与导致的临时权限
离职前的权限逐步回收

凭证变更

密码重置
MFA 设备更换
证书更新

变更管理的核心原则：

Keycloak 是什么——开源 IAM 完全指南 | IDaaS Book

Thu, 09 Jul 2026 00:00:00 +0800

Keycloak 是什么

Keycloak 是 Red Hat 赞助的开源身份与访问管理（IAM）平台，由 Keycloak 开源社区维护。它提供标准化的登录、令牌和用户联邦能力；项目的 GitHub star 数会变化，不能代替版本、兼容性或容量验证。

一句话概括：Keycloak 是你可以自己部署的 Okta / Auth0。它提供了现代应用所需的全部身份能力，你不需要支付按用户计费的钱，只需要自己运维它。

核心能力：

单点登录（SSO）：一次登录，所有接入应用免密访问
多协议支持：OpenID Connect、OAuth 2.0、SAML 2.0——全覆盖
身份联邦：对接外部身份源（LDAP、Active Directory、社交登录）
用户管理：自建用户存储 + 外部联合用户源
多因素认证：TOTP、WebAuthn/Passkey、短信验证码
细粒度授权：基于角色、组、属性的访问控制
管理控制台：Web UI + REST API + CLI（kcadm）

为什么选择 Keycloak

Keycloak vs 商业 IDaaS

对比维度	Keycloak	Okta / Auth0
许可	开源免费（Apache 2.0）	按用户数/月付费
部署	自建（Docker / K8s / Bare Metal）	SaaS（无需运维）
数据主权	完全自主控制	数据留存在供应商
定制能力	SPI 插件 + 主题化 + 源码级定制	API + 有限的配置定制
运维成本	需要团队维护	零运维
1000 用户年成本	~$0（仅服务器成本）	~$2000-6000/年

结论：如果你需要数据主权、深度定制能力、或者用户量大到按用户计费肉疼，Keycloak 是最优解。如果你团队没有 IAM 运维能力，选 SaaS IDaaS。