为什么 RP 和 IP 通过浏览器通信而不是直接通信？答案

【问题标题】：Why RP and IP communicates through browser instead of going directly?为什么 RP 和 IP 通过浏览器通信而不是直接通信？
【发布时间】：2013-12-13 13:34:23
【问题描述】：

为什么RP使用浏览器作为中介，为什么RP在认证前不能直接重定向到IP，认证后反之亦然？

我想出了一些理由，但无法说服自己..所以问你:)

1) RP 和 IP 不能保持一条连接线（反对：如果 RP 调用 STS web 服务并获取数据作为响应）

2) 管理cookies/session（反对：但是RP不能最终返回cookie吗？浏览器在每个请求中都返回它从而保持一个会话），

3) 由于数据保护政策，浏览器有责任将凭据传递给 IP（很好）

4) IP 需要知道调用者是谁（反对：为什么？）

【问题讨论】：

使用被动联合时使用浏览器。这也是直接与 STS 对话的活动联合方案。
IMO 活动场景涉及请求者调用 IP。我提到的场景是RP调用IP

标签： claims-based-identity adfs claims

【解决方案1】：

因为 RP 不能直接与 IdP 通信是一个非常典型的场景，例如RP在外网，user和IdP在内网。

另一个原因是 SSO - 您需要能够在浏览器和 IdP 之间设置 cookie。

【讨论】：

与ldP通信后不能从RP设置cookie吗？
关于RP是外部的，只是想确认一下我的理解。所以RP只有lDP的url，没有访问权限。因此它要求浏览器（用户）调用 lDP，从而发生浏览器重定向。现在我有一个问题，RP不能使用用户提供的凭据并代表用户调用ldP吗？这样我们就不能减少浏览器重定向吗？

【解决方案2】：

我一直在研究主动和被动联邦。感谢尤金.S。在被动联合中，登录窗口需要由 LDP 提供。因此，从 RP 到 lDp 的 Web 服务调用不会向浏览器（调用者）提供登录窗口。因此，在被动联合中需要浏览器重定向。

被动联合的另一个惊人发现是 RP 从不查看用户凭据。它只对令牌/cookie 感兴趣。如果未找到，则用户转到 LDP 并在那里提供凭据。正如作者在cmets中提到的(http://blogs.msdn.com/b/mcsuksoldev/archive/2010/07/07/windows-identity-foundation-101-s-ws-federation-passive-requestor-profile-part-1-of-2.aspx)

在 Active federation 中，浏览器永远不会离开 RP。 RP 获取用户凭据并发布到 LDP。要执行此操作，RP 需要有一个 Web 服务客户端。 Web 服务在 LDP(STS) 中运行。有一件事仍然困扰着我。如果 RP 可以获取用户凭据，为什么要向 LDP 询问其有效性？为什么RP不能做LDP要做的事情。例如：RP 可以直接询问活动目录，而不是询问 ADFS（旧 Windows 身份验证：P）。但随后“最小特权”使我们认识到 RP 是外部的。因此，我希望出于安全原因使用 lDP，以建立单点联系并将身份验证与所有应用程序 (RP) 分开

所以我们现在有了浏览器重定向和 no-browser-redirect-but-WS-call 的理由！！

现在开始出现另一个问题。为什么有两个联邦：主动和被动。什么时候用什么？我会找出答案的，如果不是，我将它作为一个新问题发布。

【讨论】：

我使用活动联合的场景是使用“智能客户端”，例如 Silverlight 或 WPF。就我而言，它是 Silverlight，我不希望浏览器重定向。在 WPF 中，在大多数情况下，passove federation 甚至都不是一个选项。