这是我最近一直在考虑的情况：
应用程序A和B之间有链接。为了从应用程序A到达B，工作流程如下所示：
我们希望简化用户体验：
现在，我们认为我们会像以下那样重写我们对应用B的出站链接：https://example.com/redirect?email=user@example.com&url=/the-resource
这将允许应用程序B检测是否需要SSO，如果没有其他选项，我想我们会这样做。但是，如果有一个已经建立的标准，我会喜欢它，所以我们可以要求其他公司实施相同的标准。
我知道SSO系统的检测由依赖方决定，所以也许这只是我们必须与应用程序B的作者一起解决的问题。
是否有RP到RP数据交换的标准，其中两个RP都有一个共同的身份提供者？
答案 0 :(得分：1)
我担心SAML依赖方/服务提供商没有交换信息的标准。所有协议消息都在声明提供者/身份提供者和依赖方/服务提供者之间。
代替标准，你提出的建议看起来是合理的。
答案 1 :(得分：1)
如果通过“分享信息”表示“提供有关用户IDP的提示”，则会制定一个标准https://ra21.org/。在RA21开始之前，我有一个类似的想法，我在IIW 22（https://www.internetidentityworkshop.com/proceedings.html）分享。这基本上就是你提出的建议：在URL中加入IDP提示。回复是积极的，但很少有人有一个可以使用它的用例。
我注意到我们为OpenIDConnect讨论过的提案（见周二5G，第45页）是发行人......重定向？发行人= [发行人] ...请参阅说明书中的说明理由。
如果您要共享SAML IDP，可以查看http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/cs01/sstc-saml-metadata-ui-v1.0-cs01.pdf§2.2发现提示信息。如果您的SAML IDP在其元数据中包含子元素，那么这将是IDP确定RP如何相互提示的直接方式，并且URL中的值可以是......重定向？DomainHint = [whatever]。 ......已经有好几年了，我记不清了
最后请注意，在网址中发送电子邮件地址会违反如此多的隐私期望。不要将PII放在您的URL中！
答案 2 :(得分：1)
听起来你需要一个“无人问津”的＆＃39;应用程序B的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流并获得自己的属性。
答案 3 :(得分：0)
我认为你走在正确的轨道上。这完全取决于RP是否认为它应该使用IDP，因此当您导航到应用程序B时，您只需要传递足够的上下文，以便它可以做出决定。因此，在这种情况下，“标准”将是前向通道导航到已知端点，其中包含查询字符串或散列中所需的信息。