Single sign on 是否有一个标准供两个拥有共同身份提供者的依赖方共享信息？

以下是我最近一直在考虑的一个情况：

客户有自己的身份提供者（即ADFS）

我公司的web应用程序（应用程序A）支持SAML和OpenID Conect

另一家公司的应用程序（应用程序B）也支持SAML和OpenID Connect

应用程序A和B都与身份提供程序关联

可以要求应用程序B的作者更改它

应用程序A和B之间有链接。为了从应用程序A到B，工作流如下所示：

用户已登录到应用程序A

用户单击应用程序B的链接

用户现在处于应用程序B登录屏幕

输入电子邮件地址

用户跳转到ADFS或类似系统

用户现在已登录到应用程序B并可以查看资源

我们希望简化用户体验：

用户已登录到应用程序A

用户单击应用程序B的链接

应用程序B以某种方式检测到用户正在使用SSO，并将其重定向到相应的页面

用户跳转到ADFS或类似系统。如果最后一次登录不是很久以前，那么用户应该被自动验证

用户现在已登录到应用程序B并可以查看资源

现在，我们正在考虑重写到应用程序B的出站链接，如下所示：

这将允许应用程序B检测是否需要SSO，如果没有其他选项，我想我们会这样做。然而，我希望有一个已经建立的标准来做这件事，所以我们可以要求其他公司实施同样的标准

我知道SSO系统的检测由依赖方负责，所以这可能只是我们必须与应用程序B的作者一起解决的问题

---

在两个RP都有一个共同的身份提供者的情况下，是否存在RP到RP数据交换的标准？

我认为您的思路是正确的。RP是否认为应该使用IDP完全取决于它，所以当你导航到应用程序B时，你只需要传递足够的上下文，这样它就可以做出决定。因此，在本例中，“标准”是前端通道导航到已知端点，并在查询字符串或散列中提供所需的信息

恐怕SAML依赖方/服务提供商没有交换信息的标准。所有协议消息均在索赔提供者/身份提供者和依赖方/服务提供者之间

作为标准的替代，您的建议看起来是合理的。

如果您所说的“共享信息”是指“提供有关用户IDP的提示”，则有一个标准正在开发中。在RA21开始之前，我有一个与IIW22（）类似的想法。这基本上就是你所建议的：在URL中添加一个IDP提示。反应是积极的，但是很少有人有他们可以使用它的用例

我注意到，我们为OpenIDConnect讨论的建议（见会议记录第45页，星期二5G）是发行人…重定向？发行人=[发行人]。。。有关规范的理由，请参见注释

如果您正在共享SAML IDP，您可以查看§2.2发现提示信息。如果您的SAML IDP在其元数据中包含了子元素，那么IDP就可以用一种简单的方式确定RPs如何相互提示，URL中的值可以是…重定向？DomainHint=[任何]。。。。已经好几年了，我不记得了

---

最后，在URL中发送电子邮件地址会违反许多隐私要求。不要把PII放在你的URL中

听起来您需要应用程序B的“WAYF less”URL入口点。WAYF=您来自哪里？这是发现用户与哪个IdP关联的旧方法。如果用户已经在应用程序A处进行了身份验证，则应用程序A知道该用户的IdP的entityID。用户的IdP还将为他们提供身份验证会话，因为他们已经登录到应用程序A

因此，您可以在应用程序B中：

https://applicationb.com/sso?entityID=https://some.idp.com/shibboleth

然后，应用程序B加载entityID的SAML元数据，并自动将浏览器重定向到与entityID关联的SSO URL，IdP将用户重定向回应用程序B的SAML使用者端点。用户将看不到另一个登录屏幕（除非他们的IdP会话已过期），应用程序B将获得自己的SAML属性集

在URL中共享属性并不理想，因为应用程序A可能有权查看用户的电子邮件（由IdP发布），但应用程序B可能没有。因此，最好遵循协议，让IdP将属性释放给应用程序B，而不是应用程序A所知道的关于用户的任何信息

---

A与B共享的唯一内容是用户IdP的entityID。这使得B可以开始SAML流并为自己获取属性。

我认为这接近于我在这个问题上所能得到的正确答案。您在URL中对PII提出了一个很好的观点。实际上，我们可能会使用公钥来加密值（如果我们走这条路的话），这是一种非常好的替代方法，避免了URL中的PII问题。很遗憾你不能把两个答案都标为正确答案。讨论使用webfinger发现IDP的标准方法。