通常发生的情况是您只被转发一次，重定向舞蹈（被动重定向）发生，并且您得到一个令牌。令牌通常以加密格式缓存在 cookie 中。因此，后续请求不会进行重定向舞蹈。
这里的挑战是，由于 cookie 是加密的，所以网络场中的所有服务器都必须具有加密密钥才能解密。开箱即用，您将遇到 WIF 问题，因为它默认为 DPAPI。这种类型的加密在每台机器上是故意不同的。这在云中中断。
您需要做的是上传服务证书作为部署的一部分，并将 cookie 的加密方式更改为对 webfarm 友好的内容。这是神奇的代码：
private void OnServiceConfigurationCreated(object sender,
ServiceConfigurationCreatedEventArgs e)
{
var sessionTransforms =
new List<CookieTransform>(
new CookieTransform[]
{
new DeflateCookieTransform(),
new RsaEncryptionCookieTransform(
e.ServiceConfiguration.ServiceCertificate),
new RsaSignatureCookieTransform(
e.ServiceConfiguration.ServiceCertificate)
});
var sessionHandler = new
SessionSecurityTokenHandler(sessionTransforms.AsReadOnly());
e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(
sessionHandler);
}
这会将您的安全令牌处理程序设置为将 RSA 加密与从已安装证书派生的密钥材料一起使用。
此示例应用程序中概述了更多详细信息和信息，用于说明问题和解决方案：
http://msdn.microsoft.com/en-us/library/ff966481.aspx
附加编辑：
ASP.NET 中有一个配置 WIF 的管道。它挂钩身份验证事件，并将从 cookie 中提取令牌并构建您的 IPrincipal，以便后续代码将其包含在上下文中。使用 STS 时，您通常不会自己构建 Principal。相反，如果您需要修改 Principal，您可以将插件插入 WIF 中的管道，并向“角色”声明（实际上是一个 URI 命名空间）插入其他声明。然后，WIF 将使用这些声明来构建 ClaimsPrincipal，该声明将包含诸如角色之类的内容，并且可以正常工作（IsInRole、web.config auth 等）。
如果可能，最好让令牌包含作为声明的角色。这是一个更长的讨论，但是围绕有意义的上下文的声明的“正常化”。请记住，您从 IP-STS 获得的声明是用他们自己的术语来说的，它们可能对您的应用程序没有任何意义。例如，我可能会收到客户声称他们是 Adatum\Managers 组的一部分。这对我的应用程序来说完全没有意义，所以我通常会将该令牌交换为我的应用程序理解的令牌，并在此过程中通过声明映射（即 Adatum\Managers --> MyApplicationAdminRole）转换或规范化声明。Windows Azure ACS 服务非常适用于帮助做到这一点（标准化来自不同 IP 的声明）。
我建议阅读Vittorio关于这一切的书，以了解这里的常见模式：
Eugenio 的笔记：
添加到 @dunnry 所写的内容，这都是正确的。在依赖方（您的 Web 应用程序）中增加您的声明集的适当扩展点是使用ClaimsAuthenticationManager。这种类型的文档在这里。该页面中有指向样本的指针。在该类中，您将从 XML 文件中读取角色并将它们添加到 ClaimsIdentity。该应用程序的其余部分不会担心索赔等（特别是如果您使用的是您的案例中的角色）。用于 cookie 加密的 RSA 配置解决了负载平衡器问题。