c# - Windows Azure : web application on several instances, 身份验证？

Question

我想要迁移到 Windows Azure 云的现有 Web 应用程序在(后)authenticaterequest 事件中的某处按以下方式对用户进行身份验证:

IPrincipal current = Thread.CurrentPrincipal;
if (current != null && ((IClaimsIdentity)current.Identity).Claims.Count > 0)
{
    IPrincipal result =  AuthManager.CreateGenericPrincipal(current.Identity);
    HttpContext.Current.User = result;
    Thread.CurrentPrincipal = result;
}

CreateGenericPrincipal 方法在 xml 文件中查找 ClaimsIdentity 的角色，并使用该角色创建一个新的 GenericPrincipal。需要验证的页面只需执行

IPrincipal p = Thread.CurrentPrincipal;
p.IsInRole("rolesFromXml");

这对于一个 webrole 实例来说效果很好，因为与普通 IIS 托管没有太大区别。但它仍然适用于 2、3 或 5 个实例吗？ Azure 负载均衡器不是“粘性”的，用户在使用应用程序时可能会被转发到另一个实例。不知道 Thread.CurrentPrincipal 是否仍然是可行的方法。

我在这里使用基于声明的身份。用户第一次进入页面时，他会被转发到安全 token 服务。到目前为止，这种情况只发生一次。如果在使用多个实例时多次发生这种情况，那就很烦人了..

谢谢!

Answer 1

通常发生的情况是，您仅被转发一次，重定向舞蹈(被动重定向)发生，并且您获得 token 。 token 通常以加密格式缓存在 cookie 中。因此，后续请求不会执行重定向舞蹈。

这里的挑战是，由于 cookie 是加密的，因此网络场中的所有服务器都必须具有加密 key 才能解密。开箱后，您将遇到 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);
}

这会将您的安全 token 处理程序设置为使用 RSA 加密以及从已安装的证书派生的 key Material 。

此示例应用程序中概述了更多详细信息和信息，说明了问题和解决方案:

http://msdn.microsoft.com/en-us/library/ff966481.aspx

附加编辑:

ASP.NET 中有一个配置 WIF 的管道。它 Hook 身份验证事件，并从 cookie 中提取 token 并构建您的 IPrincipal，以便后续代码在上下文中包含该 token 。使用 STS 时，您通常不会自己构建主体。相反，如果您需要修改主体，则可以插入 WIF 中的管道，并向“角色”声明(实际上是 URI 命名空间)插入其他声明。然后，WIF 将使用这些声明来构建 ClaimsPrincipal，其中将包含角色等内容以及正常工作的内容(IsInRole、web.config auth 等)。

如果可能，最好让 token 包含角色作为声明。然而，这是一个关于对有意义的上下文的主张的“正常化”的更长的讨论。请记住，您从 IP-STS 获得的声明是用其自己的术语表示的，它们可能对您的应用程序没有任何意义。例如，我可能会收到客户的声明，称他们属于 Adatum\Managers 组。这对我的应用程序来说完全没有意义，因此我通常会将该 token 交换为我的应用程序可以理解的 token ，并在此过程中通过声明映射(即 Adatum\Managers --> MyApplicationAdminRole)转换或规范化声明。 Windows Azure ACS 服务在这里非常适合帮助实现这一目标(规范来自不同 IP 的声明)。

我建议阅读Vittorio's book在此获取常见模式:

尤金尼奥的笔记:添加@dunnry 所写的内容，这都是正确的。增强您在依赖方(您的网络应用程序)中设置的声明的正确扩展点是使用ClaimsAuthenticationManager。此类型的文档是 here 。该页面中有指向示例的指针。在该类中，您将从 XML 文件中读取角色并将它们添加到 ClaimsIdentity 中。应用程序的其余部分不会担心声明等(特别是如果您使用像您的案例中那样的角色)。用于 cookie 加密的 RSA 配置解决了负载均衡器问题。