Siguiente con la serie de posts dedicada a la securización de aplicaciones, este post veremos cómo desplegar en Windows Azure Web Sites la aplicación web desarrollada en el post anterior y un par de puntos que tendremos que tener en cuenta para que todo funcione sin problemas.
- Cómo securizar aplicaciones web usando ACS y tokens JWT.
- Desplegar aplicaciones web en Windows Azure WebSites que hagan uso de WIF.
- Cómo securizar servicios WebAPI usando ACS y tokens KWT.
- Cómo securizar una aplicación MVC que contenga tanto aplicaciones web como servicios WebAPI.
- Cómo securizar aplicaciones web usando Windows Azure Active Directory ( WAAD ).
- Cómo hacer uso del tenant de WAAD de Office 365 para securizar aplicaciones web
El primer paso es crear un nuevo Web Site desde el portal de WIndows Azure dónde desplegaremos la aplicación ASP.NET desarrollada en el post anterior y que hace uso de ACS y tokens JWT.
Una vez creado el site, modificaremos en namespace de ACS para que en lugar de hacer uso las URL locales, haga uso de las URL de WIndows Azure dónde desplegaremos la aplicación.
En este caso estamos modificando la misma relaying party que teníamos ya, pero en un escenario real os recomendaría tener dos “relaying party”, una configurada para funcionar en local y otra para funcionar cuando esté desplegada en Windows Azure y hacer uso de las transformaciones que soporta web.config para que cuando ésta se despliega en Windows Azure la configuración sea modificada para tener la configuración adecuada.
El siguiente paso, será utilizar el wizard de publicación que nos proporciona el Sdk de Windows Azure para publicar de manera directamente desde Visual Studio.
Este wizard de forma sencilla nos permite indicar las credenciales de nuestra subscripción Windows Azure, así como indicar el servicio sobre el que se quiere desplegar la aplicación, tal y como se ve en las imágenes siguientes:
Y una vez desplegada, si lo hacemos con los errores remotos activados ( <customErrors mode="Off"></customErrors> ) veremos el siguiente error!!
The data protection operation was unsuccessful. This may have been caused by not having the user profile loaded for the current thread’s user context, which may be the case when the thread is impersonating.
Este error se produce por el uso DAPI, método por defecto para proteger las cookies en aplicaciones WIF y el cuál no está disponible en Windows Azure Web Sites.
Cambiarlo es sencillo, ya que la propia herramienta nos permite indicar que queremos usar un método alternativo, chequeando la opción “Enable Web farm ready cookies” en el pestaña de configuración del asistente “Identity and Access…”.
Sino podemos cambiar manualmente estas entradas en el fichero de configuración:
<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" />
