Donde explico como desarrollar e implementar MVC con autenticación en Dominio Azure.

Parte I. Creando el sitio Web

En Visual Studio 2013, hay asistentes que permiten integrar rápida y fácilmente los mecanismos de identificación centralizada provistos por Windows Azure y tus propias aplicaciones MVC.

Para comenzar es útil tener un dominio en una suscripción de Azure. (Obviamente, primero tener una suscripción… :). Hay de prueba, antes que te preocupes.Pero debes planificarlo bien, ya que duran poco http://azure.microsoft.com/es-es/pricing/free-trial/ ).

Entrando al administrador de la suscripción (https://manage.windowsazure.com), en la barra de opciones a la izquierda, selecciona Directorio Activo.
Allí podrás agregar un directorio que te permita administrar seguridad.

Al crear un proyecto nuevo, y seleccionar que el mismo será Web, existe la opción de cambiar la forma de identificación (Autenticación) de los usuarios.

Nota: lamentablemente, en ediciones anteriores de VS, era posible hacer esto DESPUÉS de haber comenzado el proyecto. En VS 2013, esa opción no aparece. 😦

Al cambiar la autenticación, permite seleccionar Autenticación de una organización, e indicar el dominio (el que creamos previamente)

Esto deja elementos de configuración en el web.config de la aplicación, que configuran la relación entre el directorio de Azure y tu aplicación.

Además, agrega al proyecto, las clases necesarias para configurar dicha relación, establecer los objetos necesarios en la base de datos predeterminada del proyecto y controlar la adecuada identificación en cada parte del sitio (manejable por atributos) .

Por otra parte, establece configuraciones en Azure, que permiten la interrelación entre tu proyecto y el dominio de autenticación, como podemos ver en la imagen 3

Entre dichas configuraciones, quiero remarcar que la url de re direccionamiento post identificación, apunta a tu propio sitio como http://localhost:[puerto] para permitirte hacer todas las pruebas necesarias.

Pasar a producción

Cuando publicamos nuestro desarrollo a un sitio web Azure, el propio proceso de publicación también nos permite relacionar el sitio publicado con nuestro mecanismo de autenticación, por una casilla de selección específica.

Sin embargo, el sitio falla ya que intenta redirigir a “localhost” :).

Si investigamos un poco, vemos que se crean entradas para cada aplicación, bajo el “dominio”, y en este caso, hay dos, una para la versión local, y otra para la publicada.

Lo que necesitamos es… cambiar el archivo de configuración.

Mantener el orden.

Lo ideal es, siempre, tratar de automatizar estos cambios, de modo de no tener que “recordarlo” cada vez.

Dado que al publicar, se procesa el proyecto en modo “release”, aprovecharemos esa circunstancia para que automáticamente se modifique el archivo de configuración para ello.

En el web.config original, estas entradas definen la autenticación con Azure.

    <add 
      key="ida:FederationMetadataLocation" 
      value="https://login.windows.net/xyz.onmicrosoft.com/../FederationMetadata.xml" />
    <add 
      key="ida:Realm" 
      value="https://UniversidadNet.onmicrosoft.com/UniversidadNet" />
    <add 
      key="ida:AudienceUri" 
      value="https://UniversidadNet.onmicrosoft.com/UniversidadNet" />
    <add 
      key="ida:ClientID" 
      value="z1y3x6ey-y891-991a-a316-36631836x1yx" />
    <add 
      key="ida:Password" 
      value="aA\A1YA8VN5AY80PAqvvcA\l868Yieoz\vfVsFHAs\U=" />

Entonces, editando el archivo web.release.config, podemos hacer que las mismas cambien por los valores correspondientes para la versión “publicada”.

En el Explorador de Soluciones, hacemos clic en el botón “ver todos los archivos”,    veremos que hay 2 archivos que extienden el web.config, entre ellos, el web.release.config que necesitamos editar.

Si vamos a la suscripción Azure, específicamente a la aplicación recién generada dentro del Directorio, podremos obtener los valores para el sitio público, en la opción de configuración.

Por cierto, vas a tener que generarte una clave para poder copiarla, ya que la autogenerada queda oculta.

Con esos datos, agregamos entradas en el web.release.config, agregándole los modificadores

xdt:Transform="SetAttributes" xdt:Locator="Match(name)"

para que reemplacen esos valores en la compilación para publicación (release),  de la siguiente forma:

    <add
      key="ida:FederationMetadataLocation"
      value="https://login.windows.net/xyz.onmicrosoft.com/../FederationMetadata.xml"
      xdt:Transform="SetAttributes" xdt:Locator="Match(name)"
      />
    <add
      key="ida:ClientID"
      value="NUEVOIDy-y891-991a-a316-36631836x1yx"
      xdt:Transform="SetAttributes" xdt:Locator="Match(name)"
    />
    <add
      key="ida:Password"
      value="aA_A1YA8VN5AY80PAqvvcA_l868Yieoz_vfVsFHAs_U="
      xdt:Transform="SetAttributes" xdt:Locator="Match(name)"
    />

• ida:FederationMetadataLocation
• ida:ClientID
• ida:Password

Solo los tres valores mostrados son necesarios, colocándoles los atributos correspondientes a la aplicación de producción

Lo mismo valdrá para cualquier configuración que utilicemos (un ejemplo típico es la cadena de conexión a la base de datos, que aparece como ejemplo en el web.release.config).

Por cierto, Gise @0GiS0 ), está publicando otras cuestiones relacionadas con Aplicaciones en Azure, como por ejemplo, crear una máquina virtual para tu sitio Web, desde Visual Studio.  http://www.returngis.net/2014/04/integracion-de-visual-studio-con-microsoft-azure-virtual-machines/