在多个服务器和子域上设置持久表单身份验证
我正在尝试跨多个服务器和子域设置表单身份验证。我为每个应用程序设置了静态机器密钥，如下所示：
<system.web>
<machineKey validationKey="574...7A7"
decryptionKey="2C3...A0D"
validation="HMACSHA256"
decryption="AES" />
</system.web>
...并且我的表单身份验证为每个应用程序配置相同：
<forms loginUrl="/login" timeout="2880" defaultUrl="/" path="/" name=".SHAREDAUTH" domain="domain.com" protection="All" />
我还尝试在我的域前加上句点，正如我看到一些人建议的那样，但是那也没用。
这在我的本地计算机上运行良好，在 IIS 中为每个子域设置了单独的站点。它在我们的开发服务器上也运行良好，其中所有站点仍然驻留在一台计算机上。然而，当我部署到临时环境时，跨域身份验证停止工作。在该环境中，我的主站点（发生登录的位置）在单个服务器上运行，而辅助站点（我的身份验证应持续存在的位置）在两个负载平衡的服务器上运行。所有这些都在 Windows 7（本地）或 Server 2008 R2（开发和登台）上的 IIS 7 下运行。
我通过在主站点上使用 MachineKey.Encode 编码字符串并在辅助服务器上使用 MachineKey.Decode 解码结果来验证机器密钥是否相同。我还通过检查 Firefox 和 Chrome 报告的请求标头以及将调试器挂钩到 Application_BeginRequest 来验证 .SHAREDAUTH cookie 是否传递到请求中的第二个应用程序Application_AuthenticateRequest。 我可以在 Application_BeginRequest 执行期间看到 cookie，但在调用 Application_AuthenticateRequest 时它就消失了。据我所知，这似乎意味着身份验证票证的反序列化失败，但我无法弄清楚为什么在多服务器环境中会发生这种情况，但除了不同的机器密钥之外，在单服务器环境中不会发生这种情况，我已经确认事实并非如此。
我还设置了自定义 MembershipProvider 和 RoleProvider，它们在每个站点上独立工作正常。
我缺少什么？
I'm trying to set up forms authentication across multiple servers and subdomains. I have static machine keys set up for each application like so:
<system.web>
<machineKey validationKey="574...7A7"
decryptionKey="2C3...A0D"
validation="HMACSHA256"
decryption="AES" />
</system.web>
...and my forms authentication is configured the same for each application:
<forms loginUrl="/login" timeout="2880" defaultUrl="/" path="/" name=".SHAREDAUTH" domain="domain.com" protection="All" />
I've also tried prefixing my domain with a period as I've seen some people suggest, but that didn't work either.
This works fine on my local machine with separate sites set up in IIS for each subdomain. It also works fine on our dev server, where all sites still reside on a single machine. When I deploy to our staging environment, however, the cross-domain authentication stops working. In that environment, I have the primary site (where login occurs) running on a single server, and the secondary site (where my authentication should persist) running on two load-balanced servers. All are running under IIS 7 on either Windows 7 (local) or Server 2008 R2 (dev and staging).
I verified that the machine keys are the same by encoding a string on the primary site with MachineKey.Encode and decoding the result on the secondary server with MachineKey.Decode. I also verified that the .SHAREDAUTH cookie is passed to the second application in the request, both by checking the request headers as reported by Firefox and Chrome, and hooking the debugger to Application_BeginRequest and Application_AuthenticateRequest. I can see the cookie during Application_BeginRequest execution, but it's gone when Application_AuthenticateRequest is called. From what I can gather, that seems to mean that the deserialization of the authentication ticket failed, but I can't figure out why that could be happening in the multi-server environment, but not the single server environment, aside from different machine keys, which I already confirmed was not the case.
I also have a custom MembershipProvider and RoleProvider set up, and those work fine independently on each site.
What am I missing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
因此，经过长时间的努力，我发现了 MS 安全公告 MS11-100，它修复了权限提升问题表单身份验证中的漏洞。不幸的是，该补丁不向后兼容。它应用于我们的负载平衡服务器，但不适用于托管创建初始登录的应用程序的服务器，这意味着平衡服务器无法反序列化应用程序服务器写入的身份验证票证。
根据 MS 部署指南文章，如果您发现自己处于这种情况，您可以添加
到 < web.config 中的 code>appSettings 部分，用于安装了补丁的计算机上的应用程序（或计算机级配置）。或者，更好的是，确保您的托管管理公司同时将补丁应用到您的所有服务器......
So, after a long slog I discovered MS security bulletin MS11-100, which patches an elevation of privilege vulnerability in forms authentication. Unfortunately, the patch is not backwards compatible. It was applied to our load balanced servers, but not to the server hosting the application that created the initial log-in, which meant that the balanced servers couldn't deserialize the authentication ticket written by the app server.
Per the MS deployment guidance article, if you find yourself in this situation, you can add
to the
appSettingssection in the web.config for applications on the machines with the patch installed (or to the machine-level config). Or, better yet, make sure you're hosting management company applies the patch to all of your servers at the same time...对我来说，可以在应用程序设置中添加此键：
For me it works adding this keys in the appsettings: