JavaScript客户端使用Federated Auth - Cross Domain访问Web服务

Question

我正在寻找一些来自联邦安全领域比我更有知识的人的最佳实践建议。

我们的情景

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

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

问题

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

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

到目前为止，根据我的研究，我想我可以发表以下声明：

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

可能的解决方案

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

如果您可以帮助我们并且可以节省时间，我会非常感谢您对上述内容发表评论。我很高兴听到我的断言也是错误的。所有新闻都是好消息......

Answer 1

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

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

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

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