asp.net - route - Autenticación federada en Azure
tag helpers asp net core (5)
Estoy usando WIF (.net 4.5) y el directorio de Azure Active para la autenticación. El sitio web se sentará en Azure.
Todo funciona como se espera a nivel local, sin embargo, cuando lo coloco en azul, aparece el siguiente error:
La operación de protección de datos no tuvo éxito. Esto puede deberse a que no se cargó el perfil de usuario para el contexto de usuario del subproceso actual, que puede ser el caso cuando el subproceso se hace pasar por otro.
Entiendo que esto se debe a que las aplicaciones no pueden usar DAPI, por lo que debo pasar a proteger mi aplicación con el MAC.
Localmente agregué esto a mi webconfig: -
<securityTokenHandlers>
<remove type="System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
<add type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</securityTokenHandlers>
como se recomienda en la documentation , y agregué una clave de máquina estática, pero no puedo encontrar ningún consejo sobre la longitud de la clave, así que he asumido 256.
Sin embargo, esta configuración simplemente da este error:
[CryptographicException: se produjo un error durante una operación criptográfica.] System.Web.Security.Cryptography.HomogenizingCryptoServiceWrapper.HomogenizeErrors (Func`2 func, Byte [] input) +115 System.Web.Security.Cryptography.HomogenizingCryptoServiceWrapper.Unprotect (Byte [] protectedData) +59 System.Web.Security.MachineKey.Unprotect (ICryptoServiceProvider cryptoServiceProvider, Byte [] protectedData, String [] para fines) +62 System.Web.Security.MachineKey.Unprotect (Byte [] protectedData, String [] para fines) + 122 System.IdentityModel.Services.MachineKeyTransform.Decode (Byte [] codificado) +161 System.IdentityModel.Tokens.SessionSecurityTokenHandler.ApplyTransforms (Byte [] cookie, Boolean de salida) +123 System.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken (Lector de XmlReader , SecurityTokenResolver tokenResolver) +575 System.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken (Byte [] token, SecurityTokenResolver tokenResolver) +76 System.IdentityModel.Services.SessionAuthenticationMod ule.ReadSessionTokenFromCookie (Byte [] sessionCookie) +833 System.IdentityModel.Services.SessionAuthenticationModule.TryReadSessionTokenFromCookie (SessionSecurityToken & sessionToken) +186 System.IdentityModel.Services.SessionAuthenticationModule.OnAuthenticateRequest (Object sender, EventArgs eventArgs) +210 System.Web.SyncEventExecutionStep. System.Web.HttpApplication.IExecutionStep.Execute () +136 System.Web.HttpApplication.ExecuteStep (paso IExecutionStep, booleano y completado sincrónicamente) +69
Eliminé la sección de clave de máquina en caso de que no hubiera especificado una clave formateada correctamente, pero el error no desaparece.
¡Qué lucha ha sido WIF!
La clave de la máquina no debería estar allí: Windows Azure genera una para usted y se asegura de que sea idéntica en cada instancia de su función.
Acerca del error que estás viendo: ¿puedes intentar borrar las cookies?
Pedirle a todos los usuarios que borren todas las cookies no era realmente una opción para mí. En este sitio y también en el libro "Programming Windows Identity Federation" encontré una mejor solución (para mí, de todos modos). Si ya está cargando un certificado SSL a Azure, puede usar ese certificado para cifrar también su cookie en todas las instancias de Azure, y no tendrá que preocuparse por las nuevas claves de máquina, los perfiles de usuario de IIS, etc.
Si no especifica machineKey en la configuración, Azure agrega uno. Pero si crea una nueva versión de su aplicación y la despliega en Azure usando la conmutación VIP, Azure genera una nueva clave de máquina para la implementación en etapas (suponiendo que su primera implementación fue en Producción). (La conmutación VIP es un buen mecanismo para implementar una nueva versión y luego cambiar las direcciones IP virtuales entre Producción y Puesta en escena).
Así que, básicamente, una solución es dejar que Azure genere la clave, pero después del cambio VIP tienes el problema. Para evitarlo, puede capturar la CryptographicException en Global.asax en el controlador Application_Error, algo como esto:
// Be sure to reference System.IdentityModel.Services
// and include using System.IdentityModel.Services;
// at the start of your class
protected void Application_Error(object sender, EventArgs e)
{
var error = Server.GetLastError();
var cryptoEx = error as CryptographicException;
if (cryptoEx != null)
{
FederatedAuthentication.WSFederationAuthenticationModule.SignOut();
Server.ClearError();
}
}
El método SignOut () hace que la cookie se elimine.
Editar : información actualizada sobre la generación de la máquina clave según lo observado por @anjdreas.
Otra solución es generar MachineKey, puede usar el Administrador de IIS para hacerlo, vea la forma más fácil de generar MachineKey para más detalles. Si coloca la misma clave en todas sus aplicaciones web dentro de Azure Web Role, el proceso de implementación de Azure no lo reemplazará.
Si usa formularios auth. puede cerrar la sesión cuando detecta la excepción y permite a sus usuarios iniciar sesión y crear una cookie válida
catch (CryptographicException cex)
{
FormsAuthentication.SignOut();
}
Simplemente borrar las cookies resolvió todo el problema para mí en este caso.