第2章核心概念解析

2、核心概念解析：身份提供商(IdP)、服务提供商(SP)、联合身份、SSO

好，咱们进入第二个核心章节。说实话，很多人在多云环境里搞身份权限，一开始就被这几个术语绕晕了。什么IdP、SP、联合身份、SSO……听着像是一堆缩写开会。其实没那么复杂，我带你一个一个拆开看。

身份提供商，简称IdP。说白了，它就是那个负责「证明你是谁」的系统。

你想想看，你在公司登录OA系统，输入用户名密码，谁在验证？是OA系统自己吗？不一定。很多时候，是后台的AD或者LDAP在干活。那个AD，就是IdP。

我个人习惯把IdP理解成「数字世界的户籍警」。它存储着用户的身份信息——用户名、密码、手机号、所属部门、角色等等。当某个应用需要知道「你是谁」时，它就会去问IdP。

  核心职责： 认证（Authentication），也就是回答「你是不是你声称的那个人」。

常见的IdP产品有哪些？

我在项目中遇到过一家客户，他们用了三个不同的IdP：本地AD管员工、Azure AD管Office 365、还有一个自建的Keycloak管内部研发平台。结果每次员工离职，IT要跑三个地方删账号，经常漏掉一个。嗯，这就是典型的IdP碎片化问题。

服务提供商，SP，就是那个提供具体功能或资源的系统。

举个例子：你们公司用的Jira、Confluence、Salesforce、或者你们自己开发的内部管理系统。这些应用本身不负责验证身份，它们只负责「你进来了，我给你干活」。它们就是SP。

SP的核心诉求很简单：「我不管你是谁验证的，只要IdP说你通过了，我就认。」

所以，SP和IdP之间需要建立一种信任关系。SP会配置一个「信任的IdP列表」，只接受来自这些IdP的认证结果。

我的经验： 配置SP时，最容易踩的坑是「回调地址（Redirect URI）」写错。我曾经因为少写了一个斜杠，调试了整整一个下午。记住，SP和IdP之间的通信，地址必须精确匹配，差一个字符都不行。

联合身份，这是多云管理的核心概念。

什么叫联合？说白了，就是「我信任你的认证结果」。比如，你在AWS上有一个IdP，在Azure上也有一个IdP。如果这两个IdP之间建立了联合信任，那么用AWS账号登录的用户，可以直接访问Azure上的资源，反之亦然。

为什么会需要这个？因为现实中，很少有企业只用一朵云。我见过的大多数客户，都是「AWS跑核心业务、Azure跑Office和AI、GCP跑数据分析」。如果每个云都单独建一套用户体系，那运维人员光记密码就得疯掉。

联合身份的实现方式，通常基于标准协议：

避坑指南： 我曾经帮一个客户做AWS和Azure的联合身份，他们想当然地以为「只要配了联合，所有用户就能自动同步」。错了！联合身份只解决「认证」问题，不解决「用户属性同步」问题。用户的姓名、邮箱、部门这些信息，还是需要另外的机制（比如SCIM协议）来同步。

SSO，单点登录，这是联合身份最直接的应用体验。

你想想看，你早上打开电脑，登录了公司门户，然后点开Jira、Confluence、GitLab、Slack……每个系统都不需要再输密码。这就是SSO。

SSO的本质是什么？是「一次认证，多个SP共享会话」。

具体流程大致是这样的：

嗯，这里要注意：SSO的体验虽然爽，但背后涉及多个重定向和令牌交换。如果网络延迟高，或者IdP挂了，所有关联的应用都会瘫痪。这就是所谓的「单点故障」——单点登录爽，单点挂了全完蛋。

  关键区别： 联合身份（Federation）是「机制」，SSO是「体验」。联合身份是实现SSO的技术基础，但SSO也可以不依赖联合身份（比如同一个IdP下的多个应用）。

好，咱们捋一捋这四个概念的关系：

说白了，联合身份是「幕后协议」，SSO是「前台体验」。IdP和SP是「角色」，联合身份和SSO是「能力」。

我在做多云架构设计时，经常跟团队说一句话：「先定IdP，再谈联合，最后优化SSO体验。」 顺序搞反了，后面全是坑。

一个小建议： 如果你刚开始做多云身份管理，不要一上来就搞复杂的联合。先选一个主IdP（比如Azure AD或者Okta），把所有云账号都联合到这个主IdP上。等跑顺了，再考虑跨IdP的联合。步子迈大了，容易扯着。

下一章，咱们聊聊具体的协议实现——SAML和OIDC到底怎么选，以及我在实际项目中踩过的那些坑。