azure - SSO 将声明添加到社交登录 (SAML WS-Fed)

Question

我正在尝试了解 SSO 概念以及它们如何适合我的情况，但我已经有点陷入困境了。假设我们使用 Azure AD、Ping Identity 或类似的东西，我们希望启用社交登录(谷歌帐户/facebook 等)——这一切都很好。我一直困惑的是如何控制附加到该身份的声明？

流程(在我的脑海中)概述:- 用户使用谷歌(Facebook等)帐户登录，他们将谷歌帐户与他们的“旧”帐户相关联(即将他们的社交登录名与我们作为企业识别他们的内部标识符链接起来)这个过程是什么，对于这个讨论来说并不重要(我不认为)。

现在，当用户使用其社交帐户登录时，如何查找其内部标识符的映射以将其添加为声明，并根据我的组织了解的信息添加该用户的相关其他声明他们(例如，如果他们超过 21 岁，他们是成员(member)的“级别”等)。

我知道，如果我们有一个使用 SSO 的 RP，那么该 RP 就可以执行此逻辑，但我们遇到的情况是，我们有多个内部(可能是外部管理的)系统(当前为 4-5 个)，我们想要将其绑定(bind)使用 SSO 一起 - 这将依赖于这些声明来进行访问/个性化等。

我见过的最接近这一点的是 RP-STS 的概念 - 根据我的研究，它可以有效地位于 Ping/AZ AD 前面，形成链的一部分，因此它可以执行内部操作根据需要查找并添加其他声明 - 这作为一个概念有意义吗？这是正确的做法吗？

我确信这不会不常见 - 但我似乎找不到任何关于我们需要的完整集成的好的示例/文档(仅 AZ AD/Ping 等)。一定有现成的产品可以做到这一点吗？ (如果可能的话，我们真的不想要自定义 SSO 实现/组件)

Answer 1

The closest I have seen to this is the concept of a RP-STS - which would effectively from what I could work out sit in front of Ping / AZ AD to form part of the chain, so so it can do the internal lookup and add additional claims as necessary - does that make sense as a concept? Is that the right approach?

这正是 RP-STS(或某些文献中的“联合提供者”)的角色。它位于您的应用程序和多个“身份提供商”之间，通常负责两件事:

1. 协议(protocol)转换(例如，您的应用可能是 WS-Fed 或 SAML，但 Facebook 是 OAuth2)
2. 声明转换和丰富(例如，根据某种逻辑添加、删除、转换声明)。

有多种实现方式，具有不同程度的复杂性/灵 active 和权衡:

1. Azure 访问控制服务可以执行#1 和(有些有限)#2。但目前尚不清楚该服务是否有任何 future ，或者是否会被 Azure AD 纳入。
2. IdentityServer 可以做到这一切。它是 OSS，因此您“拥有”它(例如托管、操作、定制等)。这是一个很好的实现，用于生产，由专家(Dominick Baier 和 Brock Allen)编写，并且非常灵活。
3. ADFS 可以做一些事情(协议(protocol)数量有限、专有的声明转换语言调试起来很复杂，但可以工作)。您必须自己托管 ADFS。这是 MSFT 的产品。

company I work for也提供类似的功能。