我将谈谈SAML，但我并不担心协议。
将有一个联邦提供商（FP）信任许多外部和1个内部身份提供商（IdP）。应用程序（SP）将依次信任FP。 SP是Java和.Net的混合体。外部IdP不知道权限并声称要添加到其安全令牌以供SP使用，但本地IdP将使用。我需要将相应的角色，权限和组关联到身份，以便SP可以适当地授予或拒绝访问权限。
我可以看到两个选项：
该领域的常见模式有哪些？
建议支持这些方案之一的产品的奖励积分（注意：不是主观的产品推荐，只是能力陈述）
更新：我对Shibboleth SP提供的功能印象深刻，尤其是它在Web服务器级别的运行方式，使应用程序免于处理SAML的责任。
答案 0 :(得分：2)
虽然我们的解决方案可能不符合您的要求，但我们已经建立了类似的东西。我们的模型是hub and spoke federation model，其中我们的中心维护有关在联合中至少进行过一次身份验证的所有用户的信息。我们按需配置用户（即：在进行身份验证时），并允许管理员在集线器中增加用户数据。我们从使用集线器的SP隐藏异构的身份验证系统集合（SAML，CAS，LDAP，OpenID Connect），并规范化传递给SP的声明。通常，在集线器的IDP侧，集线器充当服务提供商;在集线器的SP端，集线器充当身份提供者。我们发现，从SP中隔离IDP的可变性是我们SP的有效抽象。
答案 1 :(得分：0)
您描述的体系结构是托管在互联网上的产品（应用程序集）的通用设计模式，您的用户/合作伙伴可以选择提供IdP或利用您的IdP进行身份验证。许多受监管的行业要求授权由提供Web应用程序和服务的一方执行。由于您将进行授权和添加属性，因此您需要管理所有用户身份，并为这些用户配置信息到本地数据库中。收到身份验证声明后，它将使用您本地数据库中的授权信息进行扩充。
目前市场上有许多内部联合解决方案可以执行您所描述的功能。我将在这里专注于SAML解决方案，尽管联邦协议还有其他选择。几个术语所以答案更清楚。身份提供者将是发出SAML断言并且仅执行身份验证的组件，服务提供者（SP）将是网络中用于请求/接收SAML断言以及使用来自本地的授权数据来声明断言的组件数据库和用于接收身份令牌的Web应用程序，这些都是您的应用程序。
在您的网络环境中，您将拥有一个联合服务器，该服务器使用SAML协议充当所有所需IdP的SP。该组件本质上是一个联合中心。您的所有Web应用程序都将与此联合中心通信。将需要IdP发现服务来确定SAML请求的路由位置，可以在联合中心或每个应用程序中实现。我倾向于将IdP Discovery作为联合中心的一部分。有几种发现选项，例如使用URL或向用户显示选择界面，这是由需求类型和用例（劳动力，业务合作伙伴，客户）驱动的。当您的Web应用程序调用联合中心和关联的IdP发现时，SAML请求将发送到相应的IdP。收到SAML响应后，将验证断言并检索主题。根据您对解决方案的供应商和业务要求，这是一些选项发挥作用的地方。以SP角色作为接收SAML断言的联合中心的产品通常具有某种类型的插件接口或配置，允许您从本地用户数据库（或目录服务）查询属性。一旦合并了所有数据，就会发生最后一英里集成，使用SAML协议，供应商协议或Web服务到联合中心来获取所有身份信息。由于您已请求满足此用例的产品，因此我与PingFederate by Ping Identity进行了广泛合作，以解决您的目标。