Configurar la autenticación de formularios persistentes en varios servidores y subdominios

Question

Estoy tratando de configurar la autenticación de formularios en varios servidores y subdominios. Tengo teclas de la máquina estáticos creados para cada aplicación así:

<system.web> 
    <machineKey validationKey="574...7A7" 
       decryptionKey="2C3...A0D" 
       validation="HMACSHA256" 
       decryption="AES" /> 
</system.web> 

... y mi autenticación de formularios se haya configurado el mismo para cada aplicación:

<forms loginUrl="/login" timeout="2880" defaultUrl="/" path="/" name=".SHAREDAUTH" domain="domain.com" protection="All" /> 

También he intentado anteponiendo mi dominio con un período como he visto que sugieren algunas personas, pero tampoco funcionó.

Esto funciona bien en mi máquina local con sitios separados configurados en IIS para cada subdominio. También funciona bien en nuestro servidor de desarrollo, donde todos los sitios aún residen en una sola máquina. Sin embargo, cuando despliegue en nuestro entorno de ensayo, la autenticación entre dominios deja de funcionar. En ese entorno, tengo el sitio principal (donde se produce el inicio de sesión) ejecutándose en un único servidor, y el sitio secundario (donde mi autenticación debe permanecer) ejecutándose en dos servidores con equilibrio de carga. Todos se ejecutan bajo IIS 7 en Windows 7 (local) o Server 2008 R2 (desarrollo y puesta en escena).

I verificó que las teclas de la máquina son los mismos mediante la codificación de una cadena en el sitio primario con MachineKey.Encode y descodificar el resultado en el servidor secundario con MachineKey.Decode. también verifiqué que la cookie .SHAREDAUTH se pasa a la segunda aplicación en la solicitud , ambos comprobando los encabezados de solicitud según lo informado por Firefox y Chrome, y conectando el depurador a Application_BeginRequest y Application_AuthenticateRequest. Puedo ver la cookie durante la ejecución Application_BeginRequest, pero se va cuando se llama Application_AuthenticateRequest. Por lo que puedo deducir, eso parece significar que la deserialización del ticket de autenticación falló, pero no puedo entender por qué eso podría estar sucediendo en el entorno multiservidor, pero no en el entorno de servidor único, aparte de las diferentes claves de máquina , que ya confirmé que no era el caso.

También tengo un MembershipProvider y RoleProvider personalizados configurados, y funcionan bien de forma independiente en cada sitio.

¿Qué me estoy perdiendo?

Answer 1

Así que, después de un largo recorrido, descubrí MS security bulletin MS11-100, que corrige una vulnerabilidad de elevación de privilegios en la autenticación de formularios. Desafortunadamente, el parche no es compatible con versiones anteriores. Se aplicó a nuestros servidores con equilibrio de carga, pero no al servidor que aloja la aplicación que creó el inicio de sesión inicial, lo que significa que los servidores equilibrados no pudieron deserializar el ticket de autenticación escrito por el servidor de la aplicación.

Per the MS deployment guidance article, si usted se encuentra en esta situación, se puede añadir

<add key="aspnet:UseLegacyFormsAuthenticationTicketCompatibility" value="true" /> 

a la sección appSettings en el web.config para aplicaciones en las máquinas con el parche instalado (o para la configuración de nivel de equipo) O, mejor aún, asegurarse de que está empresa de gestión de alojamiento se aplica el parche a todos los servidores al mismo tiempo ...

Answer 2

Para mí funciona la adición de estas claves en las appsettings:

<add key="aspnet:UseLegacyEncryption" value="true" /> 
    <add key="aspnet:UseLegacyFormsAuthenticationTicketCompatibility" value="true" />