我已经完成了一些OpenID集成，所以我了解我要描述的问题是OpenID和OAuth可以解决的问题，但是我是SAML的新手，并试图将我的头放在一个特定的用例上：
因此，假设用户访问了Site1，它要求用户确认他或她属于哪个其他站点（Site2，Site3等）
Site1无法对用户进行身份验证，并依靠Site2或Site3进行身份验证，因此它向用户显示要进行身份验证的站点列表。
用户选择Site2或Site3，在那里进行身份验证，然后重定向回Site1。 Site1确认用户，并且现在知道用户来自何处。
问题：这是SAML要解决的有效问题吗？
答案 0 :(得分：1)
IDP通过Home Realm Discovery处理此问题。
如果为IDP配置了站点1、2和3，则当应用程序重定向到IDP时，将出现一个HRD屏幕，要求用户选择三个站点之一。
用户选择一个，进行身份验证，并通过IDP重定向回应用程序。
这不是协议功能，而是IDP功能，因为它与协议无关。
答案 1 :(得分：1)
您的问题中有两个问题：
服务提供商（Site1）需要将用户重定向到“拥有”用户身份（可以对其进行身份验证）的身份提供商（Site2，Site3等）
在身份提供者处进行身份验证，并将此事实传播回服务提供者
SAML可以解决这两个问题，但请注意以下几点：
...服务提供商可以使用的配置文件 发现主体与Web一起使用的身份提供者 浏览器SSO配置文件。在具有多个身份的部署中 提供者，服务提供者需要一种手段来发现哪个身份 委托人使用的提供者。发现配置文件依赖于cookie 在身份提供者之间通用的域中编写的 部署中的服务提供商。部署的域 预设在此配置文件中被称为通用域，并且 包含身份提供者列表的Cookie被称为 通用域Cookie。
如您所见，此配置文件依赖于公共域 cookie，该cookie由托管在公共（共享）域上的发现服务发布：
当服务提供商需要发现哪些身份提供商时， 主要用途，它调用旨在呈现共同点的交换 通过HTTP读取到服务提供商的域cookie 公共域中的服务器。
对公共域（和相关的cookie）的要求是很早就采取的，一些开发人员并不认为这是一种可以满足每个人需求的优雅方法。这导致配置文件被修改，并随后以名为{em>身份提供商发现服务协议和配置文件的separate specification的形式发布。根据此规范：
该规范定义了基于浏览器的协议，通过该协议， 集中发现服务可以提供请求服务 提供者，其身份提供者的唯一标识符可以 验证主体。本节中定义的发现配置文件 [SAML2Prof]的4.3与之类似，但是具有不同的部署属性，例如对共享域的要求。相反，这 配置文件依赖于基于规范的，基于重定向的有线协议，该协议 允许独立实施和部署服务 提供者和发现服务组件，该模型已被证明 在管理公共域的某些大规模部署中很有用 成员身份可能不切实际
提及大规模部署非常重要。第一次尝试（基于cookie的配置文件）很简单但是很混乱。改进的规范以“ SAML方式”完成了所有工作……并大大增加了实现的复杂性。仅当您的身份提供者集合足够大时才值得，例如您所在国家的所有大学。
有许多用于解决身份提供者发现问题的非SAML选项。最简单的选项是通过采用UX友好技术让用户选择其身份提供者来“询问用户”。这个blog很好地总结了这些选项。对于现实世界来说，针对此问题的复杂解决方案，请看瑞士大学的implementation。
注意：oAuth不对用户进行身份验证，而是对客户端应用程序进行身份验证。 OpenID Connect基于oAuth，可以通过id令牌对用户进行身份验证。 id令牌和相关的交换受到SAML的严重影响