我已经做了一些OpenID集成，所以我知道我将要描述的问题可以解决OpenID和OAuth可以解决的问题，但我是SAML的新手，并试图围绕一个特定的用例：
因此，假设用户访问Site1，它要求用户确认他或她属于哪个其他网站(Site2，Site3等)。
Site1 无法对用户进行身份验证，而是依赖 Site2 或 Site3 进行身份验证，因此它会向用户显示要进行身份验证的站点列表。
用户选择Site2或Site3，在那里执行身份验证，然后重定向回Site1。Site1 确认用户，现在知道用户来自哪里。
问题：这是 SAML 要解决的有效问题吗？
你的问题有两个问题：
-
服务提供商 (Site1) 需要将用户重定向到"拥有"用户身份(可以对其进行身份验证)的身份提供商(Site2、Site3 等)
-
在身份提供程序进行身份验证并将此事实传播回服务提供程序
SAML 可以解决这两个问题，但请继续阅读以下注意事项：
- SAML 中的配置文件之一是身份提供程序发现配置文件。规范中的定义(第 4.3 节)：
。服务提供商可以通过的配置文件 发现主体在 Web 中使用了哪些标识提供者 浏览器 SSO 配置文件。在具有多个标识的部署中 提供商，服务提供商需要一种方法来发现哪个身份 主体使用的提供者。发现配置文件依赖于 Cookie 在标识提供者之间通用的域中编写 和部署中的服务提供商。部署的域 预确定在此配置文件中称为公共域，并且 包含身份提供程序列表的 Cookie 称为 通用域 Cookie。
如您所见，此配置文件依赖于由托管在公共(共享)域上的发现服务颁发的通用域Cookie：
当服务提供商需要发现哪些身份提供商 主要用途，它调用旨在呈现共同点的交换 在 HTTP 读取后提供给服务提供商的域 cookie 公共域中的服务器。
通用域(和相关 cookie)要求是早期的，一些开发人员认为这不是满足每个人需求的优雅方法。这导致配置文件被修订，后来作为称为身份提供程序发现服务协议和配置文件的单独规范发布。从此规范：
此规范定义了一个基于浏览器的协议，通过该协议 集中式发现服务可以提供请求服务 具有标识提供者的唯一标识符的提供程序，该提供程序可以 对主体进行身份验证。一节中定义的用于发现的配置文件 [SAML2Prof] 的 4.3 类似，但具有不同的部署属性，例如对共享域的要求。相反，这个 配置文件依赖于规范的、基于重定向的线路协议， 允许独立实现和部署服务 提供程序和发现服务组件，该模型已被证明 在管理公共域的某些大规模部署中很有用 成员资格可能不切实际
提到大规模部署很重要。第一次尝试(基于 cookie 的配置文件)简单但混乱;改进后的规范以"SAML 方式"完成所有操作......并大大增加了实现的复杂性。仅当你的标识提供者集合规模很大时，它才值得，例如你所在国家/地区的所有大学。
有许多非 SAML 选项可用于解决身份提供程序发现问题。最简单的选项是"询问用户"，方法是采用 UX 友好的技术让用户选择其标识提供者。该博客很好地总结了这些选项。要了解这个问题的实际复杂解决方案，请查看瑞士大学的实施情况。
- 这是 SAML 非常适合的常见情况。有关更多详细信息，请查看 SAML 技术概述。
注意：oAuth 不对用户进行身份验证，而是对客户端应用程序进行身份验证。 OpenID Connect 基于 oAuth，它可以通过 id 令牌对用户进行身份验证。id 令牌和相关交换深受 SAML 的影响
IDP 通过 Home Realm Discovery 处理此问题。
如果 IDP 配置了站点 1、2 和 3，则当应用程序重定向到 IDP 时，将出现一个 HRD 屏幕，要求用户选择三个站点之一。
用户选择一个，进行身份验证，然后通过 IDP 重定向回应用程序。
它不是协议功能 - 更像是 IDP 功能 - 因为它无论协议如何都会执行此操作。