[TIP] SQL AZURE database firewall rules

Aunque no soy nada partidario de hacer crossposting de otros la verdad es que los últimos movientos en Azure casi obligan. Después de las novedades con Web Sites llega la hora de Sql Azure, con nuevas y variadas novedades que podéis ver en la siguiente lista. De entre estas novedades una que merece la pena destacar es la capacidad de aplicar reglas de firewall a nivel de base de datos y no de servidor como hasta ahora podíamos hacer desde el portal o de forma programática ( API REST o T-SQL). Para harcerlo, solamente tenemos que conectarnos a nuestro servidor y utilizar los siguientes procedimientos almacenados:

  • sp_set_database_firewall_rule: Agrega una nueva regla a nivel de base de datos, nos pide, al igual que su homónimo (sp_set_firewall_rule) para servidor, el nombre y los rangos de ip inicial y final
  • sp_delete_database_firewall_rule: Borra una regla de cortafuegos a nivel de base de datos.

Por supuesto, estas reglas en una base de datos se pueden enumerar utilizando la siguiente vista administrativa sys.database_firewall_rules.

Bien, hasta aquí este sencillo tip..

 

Unai

WIF and Web Farms

Antes o después, siempre nos encontramos con la necesidad de ‘clusterizar’ nuestras aplicaciones Web. Para esto, sin dudad ninguna, tenemos mucha documentación en la MSDN y demás portales de ayuda a desarroladores. aunque para el caso de aplicaciones haciendo uso de Windows Identity Foundation esta cantidad de ayuda no es tan grande, ni mucho menos. Por ello, a lo largo de la siguiente entrada intentaremos ver como preparar nuestras aplicaciones para que los módulos de WIF soporten WebFarms.

 

WIF 3.5

El principal escollo con el que nos encontramos para mover una aplicación a una Web Farm consiste en la encriptación de la cookie, con su consiguiente token de wif,  usando DPAPI. Como sabrá, DPAPI es dependiente de la máquina y por lo tanto, si una petición de un usuario se dirigiera hasta otro nodo del cluster este no sería capaz de realizar la desencriptación y el consiguiente tratamiento de la cookie. Por suerte, WIF nos permite modificar los módulos encargados de realizar estas tareas, para, poder decirle que use algún mecanismo de encriptado no dependiente de la máquina, como por ejemplo podría ser un RSA. La única pega, es que esto no lo podemos hacer mediante configuración y por lo tanto, tendremos que tocar nuestro código actual para mover una aplicación a una Web Farm. Los pasos a realizar son los siguientes:

 

Subscribirnos a la creación de la configuración en nuestro punto de inició de la aplicación

 

Crear nuestro CookieTransform que haga uso de RSA en vez de DPAPI

 

Establecer un SessionSecurityTokenHandler que haga uso de este mecanismo de transformación:

 

WIF 4.5

Por suerte, en WIF 4.5 todo este trabajo es realmente mucho más sencillo gracias a nuestra herramienta “Identity and Access Tool” de la que ya hablamosUntitled en otras ocasiones. Si nos fijamos en la misma, dentro de la pestaña de configuración tenemos un simple check que nos permite poner nuestra aplicación válida para una Web Farm.

Con este sencillo paso, sin tener que poner una sola linea de código ya tenemos el trabajo anterior resuelto. ¿ Como es posible esto? Pues bien, la respuesta está en que WIF ya tiene ahora, en esta nueva versión, un security token handler con las transformaciones adecuadas para que funcionen en una WebFarm, basta con ver los cambios realizados en nuestra sección IdentityModel para ver que ha pasado.

 

 

Si observa el elemento XML anterior verá como, tal y como comentábamos, se ha cambiado el SessionSecurityTokenHandler por defecto por un MachineKeySessionSecurityTokenHandler capaz de funcionar en una WebFarm.

 

 

 

 

 

 

Ha sido una entrada corta, pero espero que os resulte de interés…

 

Un saludo

Unai