第三部分：核心能力 on IDaaS Book

IAM 单点登录（SSO）架构模式、会话管理与跨域方案 | IDaaS Book

Fri, 01 Mar 2024 00:00:00 +0800

10.1 IAM SSO 的核心理念

在企业 IAM（身份与访问管理）体系中，单点登录（Single Sign-On, SSO）的核心承诺：用户只需认证一次，即可访问所有被授权的应用。 这是 IAM 体系中最直观的用户价值——也是 IAM 项目的典型起点。

这不仅是用户体验的改善，更是 IAM 安全性提升。原因很简单：

用户只需要记住一个强密码（而不是 N 个弱密码或同一个密码用 N 遍）
认证策略集中管理（强制 MFA、密码策略统一执行）
会话可以集中管理和吊销——这对于 IAM 合规审计至关重要

关于 IAM 整体概念，可先阅读 IAM 是什么；关于 SSO 依赖的协议细节见 OAuth 2.0 与 OIDC 和 SAML 2.0。

10.2 IAM SSO 的三种实现模式

模式一：中心化 SSO

所有用户和应用都注册在同一个中心 IAM 系统中。这是最常见的 IAM 部署形态。


 graph TD
 IAM["IAM / IDaaS<br/>认证中心"]
 App1["App1"]
 App2["App2"]
 App3["App3"]

 IAM --> App1
 IAM --> App2
 IAM --> App3

 style IAM fill:#e1f5fe,stroke:#0288d1
 style App1 fill:#f5f5f5
 style App2 fill:#f5f5f5
 style App3 fill:#f5f5f5

实现方式：通常通过 OIDC 或 SAML 2.0。代表：Keycloak 单域部署。

多因素认证（MFA）— IAM 安全核心：TOTP、FIDO2、WebAuthn 与自适应认证 | IDaaS Book

Sat, 02 Mar 2024 00:00:00 +0800

11.1 密码已死？

“密码就像是蟑螂——你灭不掉它，但你可以让它不再那么讨厌。”

现实情况是：

大量数据泄露涉及凭证窃取与滥用（Verizon DBIR 多年报告持续将凭证滥用列为最主要攻击途径之一）
用户平均有 100+ 个在线账户，但只使用约 5 个不同的密码
即使是最强的密码策略，用户也会想方设法绕过（如 Password123!）

MFA（Multi-Factor Authentication）不是可选项，是必需品——在 IAM 安全体系中，它是防止凭证泄露导致横向移动的最后一道防线。

11.2 认证因素分类

三种基础因素：

因素类型	说明	示例	安全性	便利性
知识	你知道什么	密码、PIN、安全问题	★★	★★★★★
持有	你拥有什么	手机、YubiKey、Token	★★★★	★★★★
固有	你是什么	指纹、面部、虹膜	★★★★★	★★★★
行为	你怎么做	击键模式、步态	★★★	★★★★★

什么叫"多因素"？

关键理解：两个密码不是 MFA，密码+短信验证码才是 MFA。

MFA 要求使用至少两个不同类型的因素。密码 + 确认密码 = 单因素。密码 + TOTP = 双因素。

11.3 常用 MFA 方案深度对比

TOTP（Time-based One-Time Password）

基于时间的动态口令，每 30 秒生成一个新的 6 位数字。

第12章：IAM 身份联邦与代理 — 跨域身份互信、联邦拓扑与协议桥接 | IDaaS Book

Sun, 03 Mar 2024 00:00:00 +0800

12.1 概念辨析

身份联邦（Identity Federation）

多个组织或域之间建立信任关系，允许用户在各自的身份域中认证，但可以访问信任域中的资源。

关键特征：跨组织边界，通过信任建立，身份数据源分布在多个组织。

身份代理（Identity Broker）

一个中心服务（Broker）作为多个外部 IdP 的前端代理，统一对外提供服务。

关键特征：中心化，一对多，身份数据仍在外部 IdP。

身份联合（User Federation）

IDaaS 系统从外部身份源（如 LDAP）导入或实时查询用户。

关键特征：IDaaS 拉取外部数据，用户在外部系统管理。

12.2 身份联邦详解

IAM 联邦拓扑模式

在企业 IAM 实践中，联邦拓扑决定了身份信任如何在组织间传递。以下是三种核心拓扑及其适用场景：


 flowchart LR
 subgraph SP_IDP["模式一：SP-IdP 直接联邦（点对点）"]
 direction LR
 IdP_A["🏢 IdP-A<br/>corp-a.com"] -->|"SAML/OIDC<br/>信任"| SP_B["📱 App-B<br/>corp-b.com"]
 end

 subgraph CHAIN["模式二：链式联邦（IdP Chain）"]
 direction LR
 IdP_C["🏢 IdP-C<br/>子公司"] -->|"联邦"| IdP_D["🏢 IdP-D<br/>母公司"]
 IdP_D -->|"联邦"| SP_E["📱 App-E<br/>合作伙伴"]
 end

 subgraph HUB["模式三：Hub-and-Spoke（中心辐射）"]
 direction TB
 HUB_CENTER["🔷 联邦 Hub<br/>Keycloak/Dex<br/>统一策略 + 协议转换"]
 SPOKE1["🏢 AD/LDAP"] --> HUB_CENTER
 SPOKE2["☁️ Google"] --> HUB_CENTER
 SPOKE3["💬 企业微信"] --> HUB_CENTER
 SPOKE4["🔑 GitHub"] --> HUB_CENTER
 HUB_CENTER --> APP1["📱 App-1"]
 HUB_CENTER --> APP2["📱 App-2"]
 HUB_CENTER --> APP3["📱 App-3"]
 end

模式	结构	信任管理	适合场景	不适合
点对点	两两建立信任关系	每对关系独立维护，N 方需 N×(N-1) 条信任链	2-3 个组织间的双边合作	组织超过 5 个时维护成本爆炸
链式	IdP 逐级传递信任	沿链路逐级验证，任一环节断裂则下游全部失效	母子公司、多层级组织架构	需要高可用性的跨域场景
Hub-and-Spoke	所有 IdP/SP 对接中心 Hub	信任集中在 Hub，Hub 做协议转换和策略统一	多 IdP 多应用的企业 IAM，是最常用的生产模式	Hub 成为单点——需要高可用部署

联邦的信任模型（以点对点为例）：

第13章：IDaaS 审计与合规 — 等保、ISO 27001 与异常检测实践 | IDaaS Book

Mon, 04 Mar 2024 00:00:00 +0800

13.1 审计的价值

身份审计不仅仅是"记录日志"，它是安全运营的三大支柱之一：

 安全三角
 ┌──────────┐
认证 ──┤ ├── 授权
 │ 审计 │
 └──────────┘

审计回答：谁，在何时，从哪里，做了什么，结果如何？

这对应了身份安全的最后一道防线——如果认证和授权都失效，审计日志是事后追溯的唯一依据。

13.2 审计事件分类

IDaaS 系统应记录的事件类型：

认证事件

事件	关键字段
登录成功	用户、时间、IP、设备、认证方式
登录失败	用户、时间、IP、失败原因
登出	用户、时间、登出方式
MFA 成功/失败	用户、时间、MFA 方式
Token 签发	用户、客户端、Scope、Token 类型
Token 吊销	用户、客户端、吊销原因
会话过期	用户、会话 ID、过期原因

授权事件

事件	关键字段
权限授予/撤销	操作人、目标用户、权限内容
角色变更	操作人、目标用户、角色变化
访问被拒绝	用户、资源、操作、拒绝原因

管理事件

事件	关键字段
用户创建/删除/禁用	操作人、目标用户
密码重置	操作人、目标用户
策略变更	操作人、策略名、变化内容
客户端创建/修改	操作人、客户端 ID
配置变更	操作人、配置项、变化内容
权限提升	操作人、提升方式、持续时间

13.3 审计日志设计

日志结构

标准化的审计日志应包含：