2

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

我们的情景

我们托管（订阅）网络服务（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. 我们是否遗漏了一些非常明显的东西？

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

4

1 回答 1

1

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

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

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

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

于 2013-08-20T13:36:57.027 回答