介绍
联合身份管理是一种可以在两个或多个信任域之间进行的安排，以允许这些域的用户使用相同的数字身份访问应用程序和服务。这称为联合身份，使用这种解决方案模式称为身份联合。
联合身份管理建立在两个或多个域之间的信任基础之上。例如，信任域可以是合作伙伴组织、业务单位、子公司等。
在当今的任何数字组织中，身份和访问管理 (IAM) 是一项专门的功能，委托给称为身份代理的服务提供商。这是一项专门在多个服务提供商之间代理访问控制的服务，也称为依赖方。联合身份管理是跨组织的两个或多个提供者之间做出的安排。
根据身份代理在联合身份管理中所扮演的角色，身份代理可能有其他名称。这些名称在整个行业中并未标准化，尽管以常见的说法使用并且可以互换使用。因此，无论何时使用这些名称，都必须在相关上下文中指定这些名称，并且根据安排，身份代理可能扮演多个角色。
这些角色包括：
身份提供者
居民身份提供者
联合身份提供者
联合提供者
常驻授权服务器
以下是每个角色的简要说明。
身份提供者负责声明带有声明的数字身份，供服务提供者使用。
居民身份提供者是针对数字身份定义的，并且不负责在其信任域内声明数字身份。有时这也称为本地身份提供者或现任身份提供者。
联合身份提供者是针对信任域定义的，并负责声明属于第二个信任域的数字身份。两者之间建立了信任关系。
联合提供者一词表示身份代理，它专门根据信任关系在多个服务提供者和多个身份提供者之间调解 IAM 操作。
驻留授权服务器是针对服务提供者定义的，并且是应用程序或服务提供者的逻辑表示所在的位置。它负责对应用程序或服务提供者进行身份验证和授权以获取所请求的访问权限。
身份联合的好处
提供无缝的用户体验，因为用户只需要记住一组凭据。
大多数实现都支持单点登录。
通过将帐户和密码管理职责委托给常驻身份提供者来避免管理开销，而不必管理多个身份孤岛。
简化数据管理和存储成本。
避免隐私和合规负担。
联合身份管理用例示例
联合身份管理提供对来自供应商、分销商和合作伙伴网络的用户的访问。
联合身份管理为并购后传统组织范围之外的新用户提供访问权限。
联合身份管理提供对来自银行等商业身份提供者的用户的访问，例如，PSD2 中的第三方支付提供者 (TPP)。提供对来自银行等商业身份提供者的用户的访问，例如，PSD2 中的第三方支付提供者 (TPP) .
联合身份管理使用国家身份提供者（例如 DigiD、Emirates ID 等）向公民提供访问权限。
联合身份管理为拥有公共组织 ID（例如 ORCID ID）的用户提供访问权限。
此外，这允许使用社交登录（注册/登录/连接），例如 Facebook、Google、LinkedIn 等。
此外，它可以用作临时安排，以支持 IAM 系统之间的转换。
入站和出站身份联合
身份联合大致分为两个领域：
入站身份联合
出站身份联合
在身份联合流程中，一个从另一个身份代理接收断言的身份代理称为入站身份联合。这允许您向您的组织的传统边界/信任域之外的身份提供对您的应用程序和服务的访问。
类似地，产生要由另一个身份代理使用的断言的身份提供者称为出站身份联合。这允许您管理的身份访问您组织的传统边界/信任域之外的应用程序和服务。
Figure 1: Identity Federation between the Enterprise and SaaS Application
图 1 说明了企业和 SaaS 应用程序之间的身份联合安排。SaaS 应用程序托管在 Azure 云中，其身份验证委托给联合提供商。企业是 SaaS 应用程序的租户和联合提供商。企业身份提供者 (ADFS) 在 Azure 云中联合提供者的相应租户中配置为联合身份提供者。因此，在云租户的联合提供者和企业身份提供者之间建立了信任。因此，企业身份提供者中的用户将能够使用他们在企业身份提供者中的身份登录到 SaaS 应用程序的相应租户。
所描述的流程是关于认证的。但是，为了让用户获得完全访问权限，他们还需要通过授权。授权可能是也可能不是这种联合安排的一部分。
身份联合与单点登录
大多数联合身份管理解决方案的实施方式是，用户无需在每个登录会话中多次证明其身份。单点登录不是身份联合的同义词。但是，它是其实施方式的副产品。
另一方面，并不是所有的单点登录实现都可以归类为身份联合。例如，基于 Kerberos 网络身份验证协议的集成 Windows 身份验证 (IWA) 是跨应用程序和服务的单点登录实施示例，但不被视为身份联合的示例，因为它仅限于特定网络。
带上你自己的身份
随着使用社交身份访问应用程序和服务的趋势，自带身份 (BYOID) 一词变得流行起来。虽然 BYOID 通常用于社会身份的背景下，但该概念适用于由政府、非政府组织或企业发布的任何联合数字身份。
用例 3、4、5 和 6 都是 BYOID 的示例，常见于客户 IAM (CIAM)。它们可以进一步划分为 BYOID，用于注册、登录和连接。尽管所有这 3 个用例都遵循类似的流程，但这些用例的目标存在细微差别。
“用于注册的 BYOID”的目标是通过检索一部分以完成在中间身份代理中为用户创建帐户所必需的个人资料信息，使用管理的身份来改善自我注册过程的用户体验由第三方。
相反，“用于登录的 BYOID”的目的是使最终用户的登录流程尽可能顺畅，同时尽可能减少额外输入的提示。用于登录的 BYOID 不一定需要在中间身份代理中配置本地帐户。
最后，“BYOID 连接”的目的只是用附加/缺失的信息丰富/填充本地用户配置文件。
联合帐户链接
联合身份提供者的关键特征之一是将多个联合身份提供者中的单个身份的数字标识符链接到常驻身份提供者中的数字标识符。 这称为联合帐户链接。
如果没有联合帐户链接，联合提供者将仅在服务提供者和联合身份提供者之间进行调解。这种联合模式常见于非关键应用和服务中，例如公共论坛、下载表格、白皮书、报告等。这可以在下面的图 2 中看到。
Figure 2: Federated login without account linking
然而，对于联合帐户链接，除了调解之外，联合提供者还可以提供帐户管理、密码管理和权利管理等功能，如图 3 所示。
Figure 3: Federated login with account linking
即时账户配置
即时帐户配置技术用于在中间身份代理中为用户即时设置帐户。 即时账户配置是即时账户链接的关键部分。图 4 更好地说明了这一概念。
Figure 4: Federated login with just-in-time account provisioning
即时密码配置
即时密码配置是即时账户配置的可选步骤。对此类供应的需求通常取决于组织的组合帐户和密码策略以及用户将访问的应用程序。如果您决定为本地帐户提供新密码，则允许用户继续使用联合身份登录也是可选的。
家庭领域发现
与单一身份提供者联合不足以满足当今的企业需求。由于需要支持多个合作伙伴或多个社交登录选项，通常会配置多个联合身份提供者（称为领域）。在这种情况下，为尝试访问应用程序或服务的特定用户选择常驻身份提供者（通常称为家庭领域）成为一项挑战，尤其是在用户体验方面。
家庭领域发现 (HRD) 是识别特定用户的常驻身份提供者的过程，以便对用户进行身份验证并通过声明断言用户的身份。HRD 最初是 Microsoft 术语，但该概念适用于所有现代身份联合。关于如何实施 HRD 没有标准。每个供应商都有自己的风格，因此很难支持可移植性。
HRD 方法可以是自动的或涉及手动用户交互。以下是一些常用的HRD方法：
向用户提供可供选择的选项列表。
标识符首次登录 — 提示用户输入自己的标识符，并根据标识符解析身份提供者。例如，如果标识符是 johann@gmail.com，我们会知道 Johann 的身份提供者是 Google，向 Google 发起身份验证请求，理想情况下，标识符会预先填写在 Google 登录表单中，以便用户不必重新输入他的标识符。
选择性家庭领域发现 — 限制用于特定服务提供者的身份提供者。这在有多个您信任的联合身份提供者但具有仅由身份提供者的特定子集中的用户使用和访问的服务提供者的情况下很有用。
使用服务提供者添加的 HTTP 查询参数。
使用用户设备的 IP 地址。例如，Intranet 用户必须使用 Active Directory (AD) 中的本地帐户登录，而 Internet 用户必须从具有多因素身份验证的上游身份提供者登录，以提高安全性。
使用通过拦截代理服务器添加的标头。
使用 cookie 来记住用户之前在设备上选择的领域。如果未找到 cookie，则回退到手动方法。
联合身份提供者本身可以是一个联合提供者，后者又与其他身份提供者联合。在这种情况下，提示用户在每个中间联盟提供商处为 HRD 提供信息，可能会被认为是糟糕的用户体验。因此，可能需要预先从用户那里收集所有可能的信息，以将其路由到正确的居民身份提供者。
支持 IAM 转换
身份联合也可以用作 IAM 的过渡策略。它可以促进从多个分散的源用户目录到单个集中的目标用户目录的转换。在这种情况下，将提供密码。最终迁移所有帐户后，您可能决定将这些管理分布式目录的联合身份提供者与生态系统断开连接。
概括
本文重点介绍联合身份管理及其用法。有许多身份联合协议，例如安全断言标记语言 (SAML2) Web SSO、OpenID Connect、WS-Trust、WS-Federation 等。虽然我们没有研究任何用于实现联合身份管理的特定协议，我们讨论的概念对于您可能选择用来实现它的任何协议都保持不变。
WSO2 Identity Server 是在 Apache 2.0 许可下分发的开源 IAM 产品。它拥有强大的身份管理和身份联合框架，使其能够在联合身份管理系统中扮演任何身份代理的角色，如本文所述。
| 本文 :https://architect.pub/what-federated-identity-management | ||
| 讨论：知识星球【首席架构师圈】或者加微信小号【ca_cto】或者加QQ群【792862318】 | ||
| 公众号 | 【jiagoushipro】 【超级架构师】 精彩图文详解架构方法论，架构实践，技术原理，技术趋势。 我们在等你，赶快扫描关注吧。 |  |
| 微信小号 | 【ca_cea】 50000人社区，讨论：企业架构，云计算，大数据，数据科学，物联网，人工智能，安全，全栈开发，DevOps，数字化. |
|
| QQ群 | 【285069459】深度交流企业架构，业务架构，应用架构，数据架构，技术架构，集成架构，安全架构。以及大数据，云计算，物联网，人工智能等各种新兴技术。 加QQ群，有珍贵的报告和干货资料分享。 |
|
| 视频号 | 【超级架构师】 1分钟快速了解架构相关的基本概念，模型，方法，经验。 每天1分钟，架构心中熟。 |
|
| 知识星球 | 【首席架构师圈】向大咖提问，近距离接触，或者获得私密资料分享。 |
|
| 喜马拉雅 | 【超级架构师】路上或者车上了解最新黑科技资讯，架构心得。 | 【智能时刻，架构君和你聊黑科技】 |
| 知识星球 | 认识更多朋友，职场和技术闲聊。 | 知识星球【职场和技术】 |
| 领英 | Harry | https://www.linkedin.com/in/architect-harry/ |
| 领英群组 | 领英架构群组 | https://www.linkedin.com/groups/14209750/ |
| 微博 | 【超级架构师】 | 智能时刻 |
| 哔哩哔哩 | 【超级架构师】 |
|
| 抖音 | 【cea_cio】超级架构师 |
|
| 快手 | 【cea_cio_cto】超级架构师 |
|
| 小红书 | 【cea_csa_cto】超级架构师 |
|
| 网站 | CIO(首席信息官) | https://cio.ceo |
| 网站 | CIO,CTO和CDO | https://cioctocdo.com |
| 网站 | 架构师实战分享 | https://architect.pub |
| 网站 | 程序员云开发分享 | https://pgmr.cloud |
| 网站 | 首席架构师社区 | https://jiagoushi.pro |
| 网站 | 应用开发和开发平台 | https://apaas.dev |
| 网站 | 开发信息网 | https://xinxi.dev |
| 网站 | 超级架构师 | https://jiagou.dev |
| 网站 | 企业技术培训 | https://peixun.dev |
| 网站 | 程序员宝典 | https://pgmr.pub |
| 网站 | 开发者闲谈 | https://blog.developer.chat |
| 网站 | CPO宝典 | https://cpo.work |
| 网站 | 首席安全官 | https://cso.pub |
| 网站 | CIO酷 | https://cio.cool |
| 网站 | CDO信息 | https://cdo.fyi |
| 网站 | CXO信息 | https://cxo.pub |
谢谢大家关注，转发，点赞和点在看。
