3

我正在使用 Azure 上的 WCF Web API 使用自定义 Api 令牌实现。这使用 FormsAuthentication.Decrypt 来获取 FormsAuthenticationTicket。为了确保 decrpyt 进程可以跨多个实例工作，我在 web.config 中提供了一个 MachineKey。但是，我注意到 MachineKey 似乎无法在 Azure 上运行，因为 Azure 似乎正在使用随机机器密钥并覆盖我在 web.config 中指定的机器密钥我正在使用最新的 Azure SDK 1.5（或1.6？）

我很清楚 Azure SDK 1.3 的这个问题，我相信这在 1.4 中得到了纠正。此问题是否有可能再次出现在 Azure SDK1.5/1.6 上？

4

5 回答 5

0

我们似乎也有同样的问题。我们在 web.config 文件中设置 machinekey 集。直到几天前 Decrypt 开始返回 null 之前，一切都很好。所有机器上的解密密钥和验证密钥都是相同的。不确定是什么问题。

编辑- Azure v1.6 似乎确实尊重我们在配置文件中设置的机器密钥。我们想出了如何解决我们的问题 - 也许这会对你有所帮助 - 我们看到 cookie 上的解密在我们的 Windows 7 64 位开发机器上不起作用。然后我们检查了挂起的更新，并且有几个与安全相关的 .NET 更新。我们运行了更新，瞧，事情又开始工作了。

于 2012-01-02T06:37:04.213 回答
0

Windows Azure 已经在部署中跨相同角色同步机器密钥。因此，您应该完全忽略 web.config 中的 MachineKey 设置，让 Windows Azure 为您处理它（Web 农场场景得到很好的支持）。Windows Azure 支持您的方案，无需修改（只需调用 Decrypt）。

您可能正在谈论的问题是 1.3 问题，其中 web.config 文件被直接修改以同步机器密钥。当文件为只读文件（即 TFS 源代码控制）并导致部署失败时，此操作失败。这是前段时间修复的。

于 2012-01-01T15:41:42.350 回答
0

我想我终于找到了解决方案。这与 Azure 或 MachineKeys 无关，但更多地与应用程序的测试方式有关。存储在我的电话应用程序上的加密密钥在不同的 Web 服务器上进行了加密（但是，使用的机器密钥是相同的）。我刚刚卸载并重新安装了我的应用程序，从而迫使服务器生成一个新密钥。

似乎在另一台服务器上解密此密钥会导致问题。我有点担心这是否会在将来引起问题。不应该使用相同的机器密钥来确保加密/解密跨盒子工作吗？

无论如何，对于给您带来的不便，我深表歉意。

于 2012-01-02T05:34:39.653 回答
0

好的，所以我在 3 服务器 NLB 组中遇到了上述问题。

看起来 Windows 自动更新已在三台服务器中的两台上安装了 KB2656352、KB2656358 和 KB2657424。

我认为这是因为有些服务器正在运行该补丁，而有些则没有。我猜已经打补丁的机器不喜欢解码由未打补丁的机器编码的东西（和/或反之亦然）。

无论如何，我已经在剩下的机器上安装了所有三个补丁，并把它放回了 NLB 组。似乎一切正常。

于 2012-01-03T06:48:44.960 回答
0

我遇到了同样的问题，在最近的 Microsoft .Net 4.0 安全升级 KB2656351 之后，我的 FormsAuthentication 票证没有跨子域进行验证。

我的 FormsAuth 票证是从我的专用服务器生成的，并在 Windows Azure 上的子域上读取。

为了让所有子域解密票证，我确保我所有的专用服务器都通过 Windows Update 使用最新的 .Net 更新进行了修补。然后我将我的 Azure 项目升级到 1.6 版，并在部署后选择了最新的 Azure OS。这似乎奏效了。

以下是有关该问题的一些文章：

http://weblogs.asp.net/scottgu/archive/2011/12/28/asp-net-security-update-shipping-thursday-dec-29th.aspx

http://technet.microsoft.com/en-us/security/bulletin/ms11-100.mspx

干杯

弗朗切斯科

于 2012-01-04T00:49:49.283 回答