JavaScript 客户端使用联合身份验证访问 Web 服务 - 跨域

Question

我正在寻找一些在联邦安全领域比我更了解的人提供的最佳实践建议。

我们的场景

我们托管（订阅）网络服务 (WCF/Asp.Net/IIS)。我们还有一个纯 JavaScript 组件（小部件），我们的客户将其嵌入到他们的 Intranet 应用程序中。小部件调用网络服务获取数据，因此我们需要小部件从他们的域向我们的域发出跨域请求。

小部件目前使用 JsonP 和 Ajax 脚本标记注入方法的组合来执行此操作。 （原因 - 小部件的年龄和对旧版非 CORS 浏览器的持续支持）。

问题

我们所有的客户都需要单点登录，因此不会要求他们的用户登录小部件。到目前为止，我们通过向新用户发出 ApiKey 并要求他们在首次使用时将其输入到小部件中来实现这一点，然后创建一个 cookie 以供以后使用。

我们需要将联合身份验证集成到此场景中。 Web 服务（在我们的域上）是依赖方 (RP)，而小部件（托管在客户域上）是客户端。身份提供者和 STS 也将位于客户域中。

从我目前的研究来看，我认为我可以做出以下陈述：

• 此方案需要主动联合方法。当 RP 是 Web 服务时，从不使用被动联合。
• 我们需要将联合端点添加到我们的 WCF 服务，以允许 Active 客户端调用我们并提供 Saml 令牌。
• 使我们的小部件成为直接与网络服务通信的活动客户端是不可能的。这将要求 Widget 请求身份并将其传递给 RP。这对于仅 JavaScript 的应用来说太过分了。

可能的解决方案

1. 在 FedAuth 场景中，实际上是否取决于小部件的主机页面（也称为客户的 Intranet 应用程序）作为客户端？
2. 我们可以提供一个代理，该代理将托管在客户域中，并充当我们 Web 服务 RP 的活动客户端。然后小部件可能不知道任何身份验证。
3. 我们是否遗漏了一些非常明显的东西？

如果您能帮助我们并抽出时间，我非常感谢您对上述内容发表评论。我很高兴听到我的断言也不正确。在这一点上，所有的消息都是好消息......

Answer 1

我们最终找到了解决方法：

对于需要 Saml 身份验证的客户，我们将小部件组件托管在我们的域中的独立网页中，他们使用 iframe 嵌入到他们的网页中。

这种方法在他们的站点中实现了小部件集成的外观，尽管与最初的预期不同，它允许我们利用被动身份验证。在这方面，iframe 的行为与普通浏览器一样，并处理与 STS 服务器的握手。

这不太理想，但我们无法想出更好的方法。它满足我们客户的需求，同时保持安全性。但这并不意味着我必须喜欢它。