我的依赖方应用程序使用 Windows Azure ACS 进行用户身份验证。我已将 ACS 配置为使用 Windows Azure Active Directory (WAAD) 作为身份提供者。这在大多数情况下都有效，用户可以使用我在 WAAD 中为他们配置的身份登录我的应用程序。但是，我遇到的问题是，如果用户登录另一个 Microsoft 帐户，并且在同一个浏览器实例中尝试登录我的应用程序，他们会收到一个丑陋的 ACS 错误“ACS20012：请求不是有效的 WS-Federation 协议消息”。例如，如果我打开 Chrome 并使用我的 Windows Live Id 登录 Windows Azure 管理门户，然后打开一个新选项卡并尝试登录我的自定义应用程序，我将收到该错误。如果我打开一个新浏览器或清除我的 cookie，我可以正常登录。
我不应该能够在同一个浏览器实例中登录这两个应用程序吗？
没有。
这是要求在同一浏览器的实例中登录两个 Google 帐户（或两个 Live ID，或任何两个帐户）（实际上可能使用 Chrome，但一般情况下是NO）。这在今天简直是不可能的。
然而，在 ACS 站点中看到该错误消息很难看。您是否在 ACS 中为您的依赖方应用程序配置了 ERROR URL ？尽管此属性是可选的，但我强烈建议客户实际使用它，并正确处理对它的请求。我没有尝试过你的特定场景，但我假设 ACS 将用户重定向到错误 URL，一旦你配置它，所以你至少知道会发生什么。
请为您的信赖方配置错误网址，并告知我们是否会将用户重定向到您的网站。然后，您将能够生成一些适当的错误消息。
更新
如果您说这仅在您登录 Azure 管理门户时发生，那么这（我的猜测！）几乎与使用 WAAD 登录相同。自 WAAD 的 GA 以来，发生了一些变化。如果您按照 Fiddler 的实际登录流程，您会注意到登录管理门户时的流程略有不同，例如登录 Hotmail。如果您登录到 Hotmail，您只会被重定向到login.live.com您的登录名并返回 Hotmail。
现在，如果您在导航到时检查流量，manage.windowsazure.com您会注意到有第一个重定向到login.microsoftonline.com（这是 WAAD 处理的！）。然后重定向到login.live.com（这是针对您的 Live ID 帐户的）。我在这里的猜测是，来自login.microsoftonline.com联邦 Live ID ( login.live.com) 的 WAAD 用于身份验证。这就是您实际使用 WAAD 登录的原因，这就是您的应用程序失败的原因。
请执行以下实验以确认我是否错了：
我怀疑现在您将能够登录到您的应用程序。