VENTAS: 1-800-867-1389

Adición de inicio de sesión en su aplicación web con Azure AD

Actualizado: mayo de 2014

noteNota
Esta muestra está obsoleta. Sus instrucciones de tecnología, métodos y/o interfaz de usuario se han reemplazado por características más recientes. Para ver una muestra actualizada que cree una aplicación similar, vea WebApp-OpenIDConnect-DotNet.

.

En este tutorial se le mostrará cómo usar Azure AD para implementar el inicio de sesión web único en una aplicación ASP.NET. Las instrucciones se centrarán en beneficiarse del inquilino de directorio asociado a su suscripción de Azure, ya que eso constituye la opción obvia de los proveedores de identidades para las aplicaciones de línea de negocio (LOB) de su propia organización.

Una solución de inicio de sesión único web normalmente conlleva la configuración de una aplicación web para externalizar sus funciones de autenticación a una entidad externa, que normalmente se conoce como proveedor de identidades (IdP). En términos concretos, esto significa que la aplicación se configurará para redirigir solicitudes no autenticadas al IdP, de acuerdo con algún protocolo de inicio de sesión como SAML-P, WS-Federation u OpenID Connect.

La autoridad (o IdP) controla la experiencia de autenticación y generalmente requiere que ya se conozca la aplicación web mediante algún proceso de aprovisionamiento. Tras la autenticación correcta, el explorador se redirige de nuevo a la aplicación web junto con un token de seguridad que lleva información acerca del usuario de entrada, la aplicación valida el token, normalmente mediante algún middleware para identidades y si la comprobación es correcta, el usuario se considera autenticado y que ha iniciado sesión.

Dicha descripción de alto nivel se aplica también a Azure AD. Este documento le mostrará cómo usar Visual Studio 2012 y las clases de Windows Identity Foundation (WIF) en .NET Framework 4.5 para configurar una aplicación de MVC 4 para que use un protocolo de inicio de sesión web. Le mostraremos cómo aprovisionar la misma aplicación en un inquilino de Azure AD, y cómo establecer la configuración de inicio de sesión de la aplicación para conectarse a dicho inquilino. Al final del tutorial, tendrá una aplicación web en funcionamiento completamente configurada para un inicio de sesión único organizativo.

El objetivo de este tutorial es ayudarle a comprender el funcionamiento de Azure AD: que requiere ir más allá de la dirección para reunir la solución simplificada que se describe aquí. Además de proporcionarle las instrucciones concretas para compilar un ejemplo de trabajo, el documento también introducirá artefactos y conceptos que resultarán de utilidad para conocer Azure AD y comprender la manera de beneficiarse de sus características más allá del escenario específico tratado aquí. Esas secciones adicionales, con formato de notas de cuadro, no son estrictamente necesarias para ejecutar el tutorial; sin embargo, si está interesado en usar Azure AD en sus propias soluciones, se recomienda que lea esas partes también.

Esta parte del tutorial de este documento se organiza en las siguientes secciones:

  • Requisitos previos: esta sección enumera todos los requisitos que deben cumplirse para completar el tutorial.

  • Arquitectura de la solución: esta sección proporciona una introducción de alto nivel del aspecto de una solución de SSO web para aplicaciones LoB (Línea de negocio). Examinaremos los componentes funcionales que hacen que se produzca el SSO, configurando el wireframe que más tarde desarrollará siguiendo las instrucciones del documento.

  • Uso del inquilino de directorio de Azure AD: esta sección presenta los inquilinos de Azure AD y las características que se reproducen en el escenario. También describirá brevemente los elementos principales de la sección de Active Directory del Portal de administración de Azure.

  • Conexión de la aplicación a Azure AD: esta sección le muestra cómo usar las herramientas de Identidad y acceso para que Access Tools for Visual Studio 2012 habilite el inicio de sesión único web en la aplicación MVC, y cómo enlazar la configuración de autenticación al inquilino de Azure AD específico que se elija.

  • Temas avanzados: esta sección va más allá de los aspectos básicos, profundizando en algunos temas clave y cubriendo algunas de las demás tareas que puede tener que llevar a cabo para mover la aplicación al siguiente nivel.

Los siguientes requisitos previos son necesarios para completar el tutorial:

Si tiene preguntas o necesita ayuda, vea Preparing for Azure AD Solutions and Scenarios

Arquitectura de aplicación con un solo inquilino

Este tutorial se centra en el escenario siguiente: un desarrollador tiene una aplicación web que planea implementar en la nube y solo desea que se les permita acceso a los usuarios de un inquilino de Azure Active Directory. Para lograrlo, necesitará:

  1. Registrar la aplicación web en su inquilino de Azure AD. Una vez que se conozca la aplicación, Azure AD aceptará las solicitudes de los usuarios para autenticarse con ella.

  2. Agregue algo delante de su aplicación, de manera que:

    1. Las solicitudes no autenticadas se puedan bloquear y redirigir hacia el inquilino de Azure AD correcto para la autenticación de usuario

    2. Los usuarios que se han autenticado con Azure AD se pueden reconocer y concedérsele acceso

Implementaremos el primer paso trabajando con el Portal de administración de Azure. Obtendrá información acerca de cómo aprovisionar un nuevo inquilino de Azure AD dentro de su suscripción de Azure, y de cómo manejar las características del Portal de administración de Azure AD para registrar una aplicación.

El paso n.º 2 se puede implementar mediante una variedad de protocolos de alto nivel pensados para permitir las operaciones de autenticación en límites organizativos, o incluso Internet.

En la plataforma .NET, el segundo paso es en esencia la configuración de las clases que .NET ofrece listas para usar para trabajar con autenticación federada e identidad basada en notificaciones. Esas clases se conocen de manera colectiva como Windows Identity Foundation (WIF) e incluyen módulos HTTP y ajustes de configuración que se pueden usar para agregar la capa de intercepción que realiza la redirección y las tareas de autenticación presentadas en el paso n.º 2. Visual Studio 2012 ofrece herramientas para ayudarle a configurar de manera automática aplicaciones web para que usen WIF para externalizar autenticación a autoridades externas que admiten protocolos SSO web específicos como WS-Federation; este tutorial le mostrará cómo usar dichas herramientas con Azure AD.

Azure Active Directory es el servicio que proporciona la red troncal de identidad de las ofertas de Microsoft como Office 365 y Windows Intune. Si se suscribe a estos servicios, y desea volver a usar el inquilino de directorio asociado a dicho servicio, cree una nueva suscripción a Azure y use la característica Agregar usuario para agregar un administrador desde dicho inquilino. Este tutorial no proporcionará instrucciones detalladas acerca de ese proceso.

Todas las suscripciones tienen un inquilino de Azure AD y un directorio asociado. Si el inquilino se generó automáticamente, el directorio se llamará Directorio predeterminado pero podrá cambiar el nombre. En esta parte del tutorial, agregaremos un usuario al directorio y, a continuación, una aplicación.

Cuando se crea un inquilino de directorio, se configura para almacenar usuarios y credenciales en la nube. Para obtener instrucciones detalladas acerca de cómo integrar su inquilino de directorio con su implementación local de Windows Server Active Directory, vea Integración de directorios.

Si tiene preguntas o necesita ayuda, vea Preparing for Azure AD Solutions and Scenarios

Los escenarios y soluciones de Azure AD (y nuestros ejemplos de código y aplicaciones de ejemplo) requieren una cuenta de usuario en el dominio de su Azure Active Directory. Si intenta iniciar sesión en las aplicaciones con una cuenta Microsoft, como Hotmail.com, Live.com u Outlook.com, se producirá un error en el inicio de sesión. Si ya tiene un usuario con una cuenta en el dominio de Active Directory, como una cuenta User@Contoso.onmicrosoft.com, podrá usarla para iniciar sesión en este escenario. De lo contrario, tendrá que crear un usuario nuevo.

  1. Vaya al Portal de administración de Microsoft Azure (https://manage.WindowsAzure.com), inicie sesión y haga clic en Active Directory. (Sugerencia para solución de problemas: falta el elemento "Active Directory" o no está disponible)

  2. Si su directorio se denomina "Directorio predeterminado", agregue un directorio, como "ContosoEngineering". Para agregar un directorio, en la parte inferior de la página de Active Directory, haga clic en Agregar y siga las instrucciones para agregar un nuevo directorio.

  3. Haga doble clic en el directorio y, a continuación, haga clic en Dominios. Cuando cree sus cuentas de usuario, use el nombre de dominio que aparece en la página. Por ejemplo, si su dominio es ContosoEngineering@onmicrosoft.com, cree nombres de usuario en ese dominio, como Test@ContosoEngineering@onmicrosoft.com.

  4. Para crear una cuenta de usuario en el dominio, haga clic en Usuarios. (Si no ve una pestaña Usuarios, haga doble clic en el nombre del directorio. Aparece una pestaña Usuarios en cada página específica de directorio.) En la parte inferior de la página, haga clic en Agregar usuario.

  5. Seleccione Nuevo usuario en la organización. Agregue un usuario en el nuevo dominio, como Test@ContosoEngineering.onmicrosoft.com y, a continuación, haga clic en la marca de verificación de la parte inferior de la página.

    Escriba el nombre de usuario y el dominio
  6. En la página Perfil del usuario, asigne un rol organizativo al usuario. Para pruebas, es mejor tener al menos un usuario con el rol Administrador global y un usuario con el rol Usuario.

    Escriba el rol de usuario

En el último paso, el Portal de administración de Azure genera una contraseña temporal que el usuario usa para iniciar sesión por primera vez. Cuando se complete el primer inicio de sesión, el usuario deberá cambiar la contraseña temporal. Asegúrese de guardar la contraseña temporal porque la necesitará para probar el escenario.

En este momento, tenemos un inquilino de directorio con un usuario válido para proporcionar una autoridad de autenticación en nuestro escenario de inicio de sesión único web.

Contraseña temporal

  1. Comencemos nuestro trabajo en los fragmentos de la aplicación. Abra Visual Studio, haga clic en Nuevo proyecto y elija Aplicación web MVC 4 de ASP.NET. En la ventana Nuevo proyecto MVC 4 de ASP.NET, seleccione Aplicación de Intranet, asegúrese de que el motor de la vista se establece en Razor y haga clic en Aceptar. En este tutorial usaremos ExpenseReport como el nombre del proyecto.

    noteNota
    En este tutorial se da por supuesto que su instalación de Visual Studio está definida con su configuración predeterminada. Si ha cambiado algunas de las configuraciones básicas (como el lugar donde se hospedan las aplicaciones web en el momento de desarrollo) tendrá que ajustar las instrucciones según corresponda.



    Nuevo proyecto en Visual Studio

    Puede aplicar las instrucciones en este tutorial a cualquier aplicación web VS 2012 existente, MVC o Formularios Web, siempre que no tenga ninguna lógica que altere de manera significativa la canalización de procesamiento de solicitudes de ASP.NET. Sin embargo, por motivos de simplicidad, aquí estamos creando un nuevo proyecto desde cero.

    noteNota
    Este tutorial ofrece instrucciones detalladas acerca de cómo configurar una solución .NET. Sin embargo, se pueden lograr los mismos resultados cuando se tienen como objetivo otras plataformas y pilas de programación. Azure AD usa protocolos abiertos en sus características de inicio de sesión web, y todas las herramientas y bibliotecas de características de plataformas principales que admiten dichos protocolos. Los pasos detallados se tendrán que ajustar para acomodar la sintaxis y las prácticas de cada pila. Sin embargo, la subdivisión de tareas de nivel alto se aplicará en el panel.

    Visual Studio crea un nuevo proyecto MVC para usted, ya configurado para ejecutarse en IIS Express: no le agregaremos más funcionalidad, ya que los valores predeterminados son suficientes para demostrar cómo agregar el inicio de sesión web. La única excepción es el extremo usado por la aplicación. De manera predeterminada, Visual Studio configura su aplicación para que sirva contenido a través de HTTP: sin embargo, eso no sería adecuado para establecer sesiones seguras, dado que dejaría las comunicaciones desprotegidas y permitiría a los atacantes potenciales robar cookies y tokens. Esto no es obligatorio durante la fase de desarrollo, ya que Azure no fuerza de manera estricta el uso de HTTPS. Sin embargo, siempre es una buena práctica.

  2. IIS Express hace que habilitar HTTPS directamente desde Visual Studio resulte muy sencillo. Seleccione su proyecto en el Explorador de soluciones y, a continuación, en el panel Propiedades, cambie SSL habilitado a True.

    Verá que la dirección URL SSL, anteriormente vacía, se rellenará con una nueva dirección. Selecciónela y cópiela en el portapapeles.



    Copiar dirección URL SSL

  3. Ahora necesitamos que Visual Studio sepa que siempre deseamos usar el extremo HTTPS durante la depuración. Regrese al Explorador de soluciones, haga clic con el botón secundario en el proyecto y elija Propiedades. Elija la pestaña Web de la izquierda, desplácese hacia abajo a la opción Usar servidor web de IIS local y pegue la dirección URL HTTPS en el campo Dirección URL HTTPS. Guarde la configuración (CTRL+G) y cierre la página de propiedades.



    Cambiar dirección URL de proyecto

    En este momento tenemos una aplicación que es adecuada para su configuración y para aprovechar Azure AD para inicio de sesión. El siguiente paso será permitir que el inquilino de Azure AD conozca esta aplicación específica.

  1. Minimice Visual Studio y regrese a la pestaña Active Directory del Portal de administración de Azure. Anteriormente en el tutorial trabajamos en el área Usuarios; ahora trabajaremos en el área Aplicaciones. En la parte superior de la página, haga clic en Aplicaciones.



    Aplicaciones integradas

    Esta área muestra las aplicaciones registradas en su inquilino de directorio. Decimos que una aplicación está registrada en un inquilino cuando:

    • La aplicación tiene una entrada en el directorio, que describe su coordenadas principales: nombre, extremos asociados, etc. Encontrará más detalles posteriormente.

    • A la propia aplicación se le ha concedido permiso para llevar a cabo algunas operaciones en el inquilino de directorio actual: las operaciones abarcan desde la solicitud del token de inicio de sesión hasta la capacidad de consultar el directorio. Una vez más, se ofrecen más detalles posteriormente.

    ImportantImportante
    Ninguna aplicación puede beneficiarse de Azure AD sin que se haya registrado: esto es así tanto por motivos de seguridad (solo las aplicaciones que el administrador aprueba deberían estar permitidas) y por consideraciones prácticas (la interacción con Azure AD conlleva el uso de protocolos abiertos específicos, que a su vez requieren el conocimiento de parámetros clave que describen la aplicación).

  2. Dado que acabamos de crear este inquilino de directorio desde cero, la lista de aplicaciones registradas está todavía vacía. De hecho, la primera entrada va a ser para la aplicación que acabamos de crear en Visual Studio: esta sección tratará por completo de su registro como aplicación.

    Dado que esta es la primera aplicación, inicie el proceso haciendo clic en el botón Agregar de la barra de comandos del Portal de administración de Azure de la parte inferior de la pantalla. A continuación, se le solicitará información con la pantalla siguiente:



    Proporcione información sobre su aplicación

    El proceso de registrar una aplicación mediante el Portal de administración de Azure se estructura como un asistente clásico, en el que las pantallas posteriores desglosan la recopilación de la información necesaria en función de sus opciones.

    La figura anterior muestra la primera de dichas pantallas. Las opciones ofrecidas son sencillas:

    • Nombre para mostrar: el texto introducido aquí se usa como moniker en lenguaje natural para consultar la aplicación siempre que un usuario, ya sea un administrador que administre la lista de aplicaciones registradas o un cliente que decida conceder acceso de directorios a la aplicación, necesita hacer algo al respecto. Hay más información acerca de esto en el documento Implementación de aplicaciones web para varios inquilinos con Azure AD.

    • Tipo de acceso: este conjunto de botones de radio le permiten especificar qué operaciones se le debería permitir a la aplicación llevar a cabo con el inquilino de directorio. A los efectos de este tutorial, en el que nuestro objetivo es simplemente configurar el inicio de sesión web con nuestra aplicación, la opción adecuada es Inicio de sesión único.

      noteNota
      Otros documentos ahondarán más en el tema de los permisos de aplicación; sin embargo, trataremos brevemente los principios subyacentes en caso de que desee saber qué ocurre en segundo plano.

      Azure AD representa aplicaciones que usan una entidad llamada ServicePrincipal. Como el nombre sugiere, esos son análogos a los principios de usuario más familiares pero se supone que se usan para describir aplicaciones.

      El acto de registrar una aplicación es, en la práctica, la creación de un ServicePrincipal para la aplicación del inquilino de la instancia del directorio a la que está pensada que tenga acceso la aplicación.

      El nivel de acceso que se debe conceder a una aplicación determinada se determina por los roles a los que pertenece el ServicePrincipal correspondiente. En este tutorial no es necesario, pero si tuviera que elegir niveles de acceso de escritura y escritura, el flujo de registro agregaría algunos pasos adicionales para recopilar más información, cómo qué claves se deben usar al llevar a cabo dichas consultas: en ese caso, las claves también se almacenarían en el ServicePrincipal que describe la aplicación. El tema Uso de la API Graph para realizar consultas a Azure AD tiene más información al respecto.

      Los permisos concedidos a través del proceso de registro de aplicación solo tienen efecto al acceder al propio directorio; no determinan las directivas de acceso para otros recursos de Azure como las bases de datos de SQL Azure, las secciones del Portal de administración y similares.

  3. Una vez introducido el nombre de la aplicación y elegido el tipo de acceso Inicio de sesión único, haga clic en la flecha de la esquina inferior derecha para pasar a la pantalla siguiente.

    Propiedades de aplicación En esta pantalla el Portal de administración de Azure recopila coordenadas importantes que el servicio necesita para dirigir el flujo del protocolo de inicio de sesión. Esto es lo que tiene que introducir:

    • APP URL: este parámetro representa el address de su aplicación web. En este ejemplo, esto se corresponde con https://localhost:44341/, la dirección asignada por IIS Express a su aplicación. Si ha seguido las instrucciones de manera exacta hasta ahora debería tenerla en el portapapeles, lista para pegarla. El valor que ha introducido tendrá vigencia durante la duración de la fase de desarrollo: una vez que implemente su aplicación en su entorno de producción o provisional de destino, tendrá que regresar al Portal de administración y modificar la dirección para que coincida con la ubicación de la nueva aplicación. Posteriormente, en el tutorial, hablaremos de cómo hacerlo.

      WarningAdvertencia
      Azure AD necesita conocer la dirección de su aplicación de manera que, una vez que un usuario se haya autenticado correctamente en las páginas de Azure AD, pueda redirigir de nuevo el flujo a la aplicación.

      Es obligatorio proporcionar esta dirección de antemano: si Azure AD redirigiera los flujos de autenticación a cualquier dirección, sería más sencillo para los atacantes secuestrar flujos de autenticación y robar tokens. El registro de la dirección URL de la aplicación por adelantado garantiza que los tokens de autenticación pensados para la aplicación solo se enviarán a la aplicación.

    • APP ID URI: este parámetro representa el identifier de su aplicación web. Azure AD usa este valor en tiempo de inicio de sesión, para determinar que la solicitud de autenticación está pensada para habilitar a un usuario para que acceda a esta aplicación concreta, entre todas las registradas, de manera que se pueda aplicar la configuración correcta.

    noteNota
    El APP ID URI debe ser único dentro del inquilino del directorio. Un valor predeterminado correcto para el mismo es el propio valor APP URL. Sin embargo, con dicha estrategia, la restricción de exclusividad no siempre es sencilla de respetar: el desarrollo de la aplicación en entornos de hospedaje local como IIS Express y Azure Fabric Emulator tiende a producir un intervalo restringido de direcciones que se volverá a utilizar por varios desarrolladores o incluso varios proyectos desde el mismo desarrollador. Una posible estrategia es anexar algo al valor de APP URI como un diferenciador.

    Tenga también en cuenta lo siguiente. El APP ID URI es un URI, y como tal no tiene que corresponder con cualquier extremo direccionable de red. Eso significa que puede elegir algo que no tenga nada que ver con la APP URL: de hecho, aunque en este tutorial estamos trabajando con una aplicación nueva, registraremos de manera ocasional las aplicaciones existentes que puede que ya tengan su propio APP ID URI (en el protocolo de inicio de sesión usado aquí, WS-Federation, APP ID URI se denomina realm) y en ese caso deseará usarlo aquí. En el tema Implementación de aplicaciones web para varios inquilinos con Azure AD resaltaremos algunas restricciones adicionales que presentan los inquilinos múltiples.

  4. Una vez haya introducido la APP URL y el APP ID URI puede hacer clic en el botón de casilla de la esquina inferior derecha.

    Inicio rápido De esa manera se concluye el proceso de registro, su aplicación tiene ahora su propia entrada en el inquilino de directorio y Azure AD estará listo para controlar la autenticación web en su nombre.

    La pantalla en la que se le informa del registro correcto le ofrece la información que necesita para configurar su aplicación web para usar Azure AD para el inicio de sesión. Es decir, la sección Habilitar el inicio de sesión único con Azure AD contiene un par de configuraciones que tendrá que pegar de nuevo en Visual Studio.

    Mantenga su explorador abierto en esta página y regrese a Visual Studio para la siguiente tarea del tutorial.

Ahora que Azure AD está listo para emitir tokens de autenticación para la aplicación, el último paso para habilitar el inicio de sesión web será configurar la propia aplicación para controlar solicitudes con el protocolo de autenticación correcto. La aplicación del protocolo es lo que permite que la aplicación invoque Windows Azure AD, y de manera específica, su inquilino de directorio, para encargarse de la autenticación del usuario al comienzo de la sesión de trabajo de un usuario con la aplicación.

Es importante comprender algo de la información de fondo sobre los mecanismos de autenticación cuando se usan protocolos de inicio de sesión web. Encontrará más detalles en la sección avanzada.

La plantilla de proyecto que hemos elegido es la aplicación de Intranet de MVC 4. Dicha plantilla normalmente depende de la autenticación integrada con Windows para garantizar que el usuario de la aplicación está autenticado. Dicho mecanismo opera en el nivel de red: se aplica a cualquiera de los servicios publicados en la intranet, sin la necesidad de agregar cualquier lógica de autenticación a la propia aplicación.

Cuando implementa una aplicación fuera de su intranet, como es el caso de las aplicaciones en la nube, ya no podrá depender de la autenticación a nivel de red. La estrategia más habitual para tratar la autenticación en esos casos incluye algún tipo de middleware delante de la aplicación, lo cual recrea en un nivel superior la comprobación de autenticación necesaria. La capa adicional puede ocuparse de la intercepción de solicitudes no autenticadas, forzando protocolos de autenticación, redirigiendo usuarios para autenticar fuera de la aplicación, devolviendo a la aplicación información acerca del usuario autenticado, administrando sesiones y en general todas las tareas que son necesarias para el control de acceso.

Esta estrategia se aplica de manera coherente en la industria en todas las opciones de plataformas, pilas de desarrollo y protocolos de inicio de sesión; lo que va en línea y el modelo de programación pueden variar pero el patrón general permanece casi igual.

En este tutorial vamos a conectar la aplicación a Azure AD mediante el protocolo de WS-Federation: esta es solo una de las posibles opciones para implementar SSO web, siendo SAML-P la otra opción más habitual.

.NET Framework 4.5 admite WS-Federation de manera nativa: todas las clases necesarias para aplicar el flujo de protocolo, la autenticación de procesamiento y las sesiones de control en el contexto de las aplicaciones ASP.NET están presentes en la caja.

En pocas palabras, .NET 4.5 ofrece un conjunto de HttpModules que tienen por finalidad que se cree una instancia de ellos en la canalización HTTP de la aplicación. Esos módulos están diseñados para hacer referencia a secciones de configuración bien conocidas, que contienen las coordenadas de protocolos de la aplicación y de la autoridad de autenticación (en este caso, su inquilino de Azure AD). A medida que se produce la entrada del flujo de la solicitudes, los módulos las examinan y aplican el protocolo de autenticación de manera adecuada: por ejemplo, tras la recepción de una solicitud no autenticada, los módulos leerán las coordenadas del inquilino de Azure AD desde la configuración, las usarán para crear el mensaje de inicio de sesión de WS-Federation y la usarán para redirigir al usuario de manera automática para autenticar con Azure AD.

noteNota
El subconjunto de clases en .NET Framework 4.5 dedicado a las tareas relacionadas con la identidad para notificaciones se conoce como Windows Identity Foundation (WIF). Las aplicaciones que tienen como objetivo versiones anteriores de .NET Framework (3.5 y 4.0) también pueden implementar los pasos descritos en este tutorial, beneficiándose de una versión anterior de WIF que se publicó fuera de banda como biblioteca independiente (descargar aquí). Sin embargo, tenga en cuenta que las instrucciones detalladas variarían, dado que las dos versiones no son completamente compatibles (las clases se encuentran en diferentes espacios de nombres) y que tendría que usar versiones de Visual Studio diferentes (2008 y 2010, descargar aquí).

Visual Studio 2012 ofrece herramientas para apuntar y hacer clic que pueden ayudarle a configurar aplicaciones para usar WS-Federation para inicio de sesión web: puede usar la interfaz de usuario de la herramienta para proporcionar alguna información clave acerca de la autoridad que desea que confíe en la autenticación y la herramienta emitirá las entradas de configuración correspondientes. En este tutorial tendrá que escribir muy poco código, gracias al hecho de que las herramientas generarán de manera automática la mayor parte del trabajo para usted.

  1. Ahora que sabe cómo vamos a implementar el inicio de sesión web, vamos a usar la herramienta de identidad y acceso para configurar la aplicación. En el Explorador de soluciones, haga clic con el botón secundario en el proyecto de la aplicación y, a continuación, haga clic en Identidad y acceso… en el menú contextual.

    Identidad y acceso Visual Studio mostrará el diálogo descrito a continuación.

    Proveedores de identidad y acceso Realizará todo su trabajo en la pestaña Proveedores, la mostrada actualmente. Para la finalidad de este tutorial, pasaremos por alto todas las opciones que no necesitamos para la tarea que tenemos entre manos.

  2. La herramienta muestra distintos tipos de autoridad que puede usar para externalizar la autenticación. En nuestro caso específico, nos interesa usar un proveedor de identidades empresarial: haga clic en la entrada correspondiente, la segunda opción desde el principio.

    Configurar identidad y acceso Conforme seleccione la opción, los elementos de la interfaz de usuario correspondientes se mostrarán en el panel siguiente. La información solicitada por dichos controles coincide de manera exacta con las entradas mostradas al final del proceso de registro de la aplicación descrito en la sección anterior. Esto es lo que tiene que introducir, de abajo a arriba:

    • Introducir el APP ID URI (territorio) de la aplicación: este es el identificador de su aplicación, como lo ha definido durante el registro. Regrese a la ventana del explorador que muestra el Portal de administración, copie el valor correspondiente del campo Actualizar su código con su App ID URI y péguelo aquí.

    • Introducir la ruta en el documento de metadatos STS: el “documento de metadatos STS” es un archivo que contiene una descripción legible por máquina de la autoridad a la que desea conectarse: la herramienta lo consumirá para determinar el valor de los parámetros que son esenciales para el flujo de inicio de sesión (más detalles a continuación). Cada inquilino de Azure AD expone un documento de este tipo; su ubicación se proporciona al final del proceso de registro. Cambie al Portal de administración, copie el valor correspondiente de la página de registro de aplicación, regrese a la herramienta y pegue la ruta en este campo.

      noteNota
      Conforme pegue en el cuadro de texto la ruta al documento de metadatos, la herramienta mostrará una advertencia acerca de que un certificado no es válido. Eso se debe al hecho de que el documento de metadatos está firmado con un certificado de firma automática y no debe ser motivo de preocupación.

    Presione Aceptar. La herramienta llegará al documento de metadatos especificado, leerá las coordenadas de la autoridad (dirección de los extremos que se usarán para inicio de sesión; el certificado X.509 que se usará para comprobar la firma de los tokens de autenticación; el formato y la versión de los tokens de autenticación emitidos) y usarán dicha información para generar y agregar al archivo web.config las entradas necesarias para conectar la aplicación a Azure AD.

En la lista siguiente se describen las entradas principales agregadas al archivo web.config por la herramienta. Para una descripción más detallada, consulte la sección avanzada del documento.

  • Entradas <section> para system.identityModel y system.identityModel.services: son necesarias para que la configuración comprenda los ajustes de configuración específicos de la identidad.

  • Configuración de <authorization> en <system.web>: la herramienta cambia automáticamente los ajustes de configuración de autenticación de ASP.NET existentes que requieren que se autentique cada solicitud a la aplicación. Esto fuerza el comportamiento denominado “redirección abierta”, en el que todas las solicitudes no autenticadas se redirigen a la autoridad de autenticación (frente al hecho de tener partes de la aplicación disponibles para los usuarios no autenticados). Dicho comportamiento es el predeterminado en las aplicaciones LoB, donde la autenticación es a menudo silenciosa dado que el usuario ya ha iniciado sesión con la autoridad. Si el desarrollador desea cambiar este comportamiento para proporcionar requisitos de autenticación en función de cada caso, simplemente puede cambiar la configuración de <authorization> en consecuencia.

  • WSFederationAuthenticationModule (FAM) y SessionAuthenticationModule (SAM) en <system.webServer/modules>: esas entradas agregan en la canalización HTTP de la aplicación los HttpModules que se ocupan de forzar el uso de WS-Federation para autenticación. El FAM es el módulo responsable de la aplicación del protocolo: es responsable de las solicitudes de inicio de sesión y de la administración de cierre de sesión de validación de token. El SAM controla sesiones: de manera específica, genera cookies de sesión, las valida y aplica su presencia en todas las solicitudes, controla la duración de la sesión, etc. Este comportamiento se controla por el elemento de configuración descrito a continuación.

  • La sección <system.identitymodel/identityConfiguration>: este elemento determina el comportamiento de la aplicación durante la fase de autenticación. Por ejemplo: en el subelemento ValidatingIssuerNameRegistry almacena la lista de autoridades que son de confianza para proporcionar servicios de autenticación, grabando sus nombres y los certificados que usan para firmar.

  • La sección <system.identitymodel.services/federationConfiguration>: esta sección ofrece las coordenadas necesarias para dirigir los flujos de WS-Federation: la dirección de la autoridad que se va a usar para solicitudes de inicio de sesión, el identificador de la propia aplicación que se va a incluir en las solicitudes, etc.

La configuración generada automáticamente es todo lo que necesita para beneficiarse de Azure AD para el inicio de sesión web: no tiene que escribir ningún código específico de autenticación en la propia aplicación. Si desea acceder a la información de la identidad del usuario, puede hacerlo fácilmente consultando las notificaciones en la entidad principal actual. Por ejemplo, supongamos que desea acceder al nombre y apellidos de su usuario actual. Podrá hacerlo mediante el siguiente código, sin la necesidad de saber nada acerca de cómo tuvo lugar la autenticación:

//...
using System.Security.Claims;

namespace ExpenseReport.Controllers
{
  public class HomeController : Controller
  {
    public ActionResult Index()
    {            
      ClaimsPrincipal cp = ClaimsPrincipal.Current;
      string fullname = 
             string.Format("{0} {1}", cp.FindFirst(ClaimTypes.GivenName).Value,
             cp.FindFirst(ClaimTypes.Surname).Value);
      ViewBag.Message = string.Format("Dear {0}, welcome to the Expense Note App", 
                        fullname);
      return View();
     }
//...

A partir de .NET 4.5, todas las identidades de .NET se representan con un ClaimsPrincipal. En este caso, el ClaimsPrincipal actual se ha construido durante la validación de un token de autenticación generado por Azure AD y presentado por el usuario en el momento de iniciar sesión.

Cada ClaimsPrincipal contiene una colección de notificaciones, atributos que describen el usuario actual como evaluado por la autoridad que lo autenticó. En nuestro tutorial, las notificaciones de la entidad principal son las emitidas en el token por Azure Active Directory: para una lista completa de las notificaciones disponibles, consulte la documentación en línea.

Azure AD emite un conjunto fijo de notificaciones para los usuarios autenticados. A continuación, encontrará una referencia rápida de todas las notificaciones que puede esperar de Azure AD; encontrará una descripción completa en la documentación.

 

Tipo Valor en ejemplo Descripción

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

S40rgb3XjhFTv6EQTETkEzcgVmToHKRkZUIsJlmLdVc

Identificador dirigido, único, inmutable, no reutilizable del usuario autenticado para la aplicación actual

http://schemas.microsoft.com/identity/claims/objectidentifier

528b2ac2-aa9c-45e1-88d4-959b53bc7dd0

Identificador para el usuario en el directorio. Útil para consultas de directorio acerca del usuario.

http://schemas.microsoft.com/identity/claims/tenantid

cab1a5ac-f33b-45fa-9bf5-f37db0fed422

Identificador del inquilino de directorio

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

John

Nombre proporcionado del usuario

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

user@test04-realm2

UPN del usuario

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

Doe

Apellido del usuario

http://schemas.microsoft.org/identity/claims/identityprovider

https://sts.windows.net/cab1a5ac-f33b-45fa-9bf5-f37db0fed422/

Identificador de la autoridad que autenticó al usuario, como se expresa en el protocolo de inicio de sesión web (en este caso, WS_Federation)

En este momento, su aplicación tiene todo lo que necesita para mostrar el inicio de sesión web con Azure AD; sin embargo, no se ha completado todavía. Hay al menos otras dos características importantes que deseará agregar: soporte para cierre de sesión y actualización automática de las coordenadas del protocolo de la autoridad.

En las siguientes dos secciones se detallará la manera de agregar esas dos características: se recomienda que las revise también antes de pasar a la sección “Ejecutar la aplicación”.

Los protocolos de inicio de sesión web en uso en la actualidad incluyen a menudo disposiciones para llevar a cabo operaciones de cierre de sesión distribuidas: esos son flujos en los que no solo la aplicación actual cancela su sesión del usuario actual, sino que también alcanza a la autoridad para señalar que un comando de cierre de sesión debe propagarse a todas las sesiones de las demás aplicaciones que pueden haberse establecido por la misma autoridad. WS-Federation no es ninguna excepción y ofrece un flujo de cierre de sesión completo implementado totalmente en el modelo de objeto de WIF. En esta subsección trataremos sobre cómo agregar capacidades de cierre de sesión distribuido a la aplicación de ejemplo: eso se reduce a proporcionar los enlaces correctos en la experiencia de usuario para desencadenar el flujo de cierre de sesión y a generar el mensaje de cierre de sesión adecuado para establecer en su inquilino de Azure AD.

  1. Comience agregando un controlador SignOut a la aplicación. Puede hacerlo con facilidad buscando la carpeta Controladores debajo del proyecto en el Explorador de soluciones, haciendo clic con el botón secundario en él y eligiendo Agregar. A continuación, tendrá que clic en Controlador. DenomíneloSignOutController, elija Empty MVC Controller (generalmente es la configuración predeterminada) y, a continuación, haga clic en Agregar.

  2. Necesitaremos usar clases desde algunos nuevos ensamblados, de ahí que tendremos que agregarles referencias. De nuevo, en el Explorador de soluciones, haga clic con el botón secundario en el nodo Referencias, elija Agregar referencia…, escriba system.identitymodel.services en el campo Buscar ensamblados y seleccione el ensamblado correspondiente en la lista principal. Presione Aceptar.

  3. Regrese al archivo SignOutController.cs recién creado. Agregue a las directivas de uso las siguientes entradas:

    using System.IdentityModel.Services;
    using System.IdentityModel.Services.Configuration;
    
    Ahora cambie la implementación de la clase SignOutController de la siguiente manera:

    public ActionResult Index()
    {
        return View("SignOut");
    }
    
    public void SignOut()
    {
         WsFederationConfiguration fc = 
                FederatedAuthentication.FederationConfiguration.WsFederationConfiguration;
    
         string request = System.Web.HttpContext.Current.Request.Url.ToString();
         string wreply = request.Substring(0, request.Length - 7);
    
         SignOutRequestMessage soMessage = 
                         new SignOutRequestMessage(new Uri(fc.Issuer), wreply);
         soMessage.SetParameter("wtrealm", fc.Realm);
    
         FederatedAuthentication.SessionAuthenticationModule.SignOut();
         Response.Redirect(soMessage.WriteQueryString());
    } 
    
    
    Esta es una explicación rápida de lo que hace el código.

    • El primer método, Index(), sirve la solicitud del formulario https://localhost:44341/SignOut. Esa es la dirección de una vista que agregará en algunos pasos más adelante en el tutorial. Su finalidad es señalar un cierre de sesión correcto y lo usaremos como tal en el siguiente método.

    • El método SignOut() sirve la solicitud del formulario https://localhost:44341/SignOut/SignOut y contiene la lógica de cierre de sesión principal.

    • La primera línea recupera el objeto que WIF usa para realizar un seguimiento de la configuración de WS-Federation en el archivo web.config: necesitaremos elaborar un mensaje de cierre de sesión adaptado a la aplicación actual.

      noteNota
      Refiriéndonos a los valores de configuración, frente a los valores de código rígido o externalizándolos desde repositorios personalizados, suele ser una buena práctica dado que hace que su código sea adaptativo y esté alineado con el resto de la configuración del protocolo: la lógica seguirá funcionando sin importar cuántas veces se cambia la configuración en el archivo de configuración, antes y después de la implementación.

    • La segunda y tercera línea crean la dirección de remite que deseamos que use la autoridad al final del flujo de cierre de sesión. Deseamos que dicha dirección señale a la Vista tratada anteriormente: así pues, el código obtiene la dirección URL de la solicitud actual y elimina el ‘SignOut’ final. La derivación de la dirección de la solicitud garantiza que resuelve correctamente para el cliente, mientras que la obtención de la dirección de la capa de hospedaje puede dar lugar a problemas de puertos internos al usar un equilibrador de carga.

    • La cuarta línea usa WIF para elaborar un mensaje de cierre de sesión de WS-Federation, pasando la dirección URL de la autoridad y la dirección de remite definida una línea antes. Podría crear con facilidad el mensaje directamente en su forma de cable. Sin embargo, el uso del modelo de objeto de WIF le ayudará a escribir código más conciso y a ignorar la mayoría de los detalles de sintaxis. Si está interesado en ver el aspecto de un mensaje de cierre de sesión, asegúrese de capturar un seguimiento HTTP cuando ejecute la aplicación en una sección posterior o consulte aquí la especificación.

    • La cuarta línea agrega al mensaje el identificador de la aplicación actual, como se registra en el atributo realm del elemento de configuración <wsFederation>.

    • La quinta línea usa el SAM (descrito anteriormente en la descripción de configuración autogenerada) para limpiar la sesión local: eso incluye la eliminación de la cookie de sesión generada en el momento de inicio de sesión, y cualquier limpieza de recursos local que pueda ser necesaria.

      noteNota
      La aplicación de ejemplo mostrada aquí no hace mucho pero sus aplicaciones reales pueden asignar recursos durante la sesión de un usuario. Si ese es el caso, puede beneficiarse de los eventos del SAM SigningOut y SignedOut agregando los controladores de eventos correspondientes en el archivo Global.asax para limpiar los recursos que se deban desechar tras cerrar una sesión.

La vista usada aquí va a ser muy sencilla: como se ha mencionado, su finalidad solo es crear un punto de retorno significativo para el flujo de cierre de sesión.

  1. En el Explorador de soluciones, haga clic con el botón secundario en el nodo Vistas y agregue una carpeta SignOut.

  2. En esa carpeta, para agregar una vista haga clic con el botón secundario en la carpeta y haga clic en Agregar. A continuación, haga clic en Vista. Llame también a la nueva vista SignOut. Coloque algún código de presentación de marcador de posición en el archivo de Vista (SignOut.cshtml) para señalar que tuvo lugar ese cierre de sesión. Por ejemplo:

    @{
        ViewBag.Title = "SignOut";
    }
    
    <h2>You have successfully signed out</h2>
    
  3. Como puede que recuerde de la sección anterior, hemos configurado la aplicación para controlar la autenticación mediante redirecciones abierta. Eso significa que, si intentamos acceder a esta Vista tras un cierre de sesión correcto (como se supone que debemos hacer) se nos redirigirá inmediatamente a Azure AD para iniciar sesión de nuevo. Para evitar ese comportamiento, puede usar el elemento <location> del archivo web.config para crear una excepción a la directiva de autenticación.

    Encuentre la primera aparición del elemento <system.web>, y justo encima de él pegue el siguiente fragmento:

      <location path="SignOut">
        <system.web>
          <authorization>
            <allow users="*" />
          </authorization>
        </system.web>
      </location>
    
    
    Eso indica a ASP.NET que todo el mundo puede acceder a la ruta SignOut, incluidos los usuarios no autenticados. Esta organización le permitirá ver esta vista representada en su explorador incluso tras un cierre de sesión correcto.

  1. Ahora que la aplicación tiene la capacidad de cerrar sesión, todo lo que queda es mostrar la característica a la experiencia del usuario. Esta es una manera muy sencilla de lograrlo: abra _layout.cshtml desde la ruta Views\Shared en el explorador de soluciones. Busque la cadena “Hello”, para encontrar el código que se ocupa de representar la información de inicio de sesión de la parte superior del diseño de MVC 4 típico y, a continuación, modifique la sección de inicio de sesión de la siguiente manera:

    <section id="login">
      @if (Request.IsAuthenticated)
      {  
        <text> Hello, <span class="username">@User.Identity.Name</span>! 
      @Html.ActionLink("Signout","SignOut", "SignOut")</text>
      }
      else {
        <text>  You are not authenticated </text>
      }
    </section> 
    
    

Eso agregará un comando de cierre de sesión a la derecha del saludo del usuario registrado, de manera que se puede desencadenar una acción de cierre de sesión desde cualquier vista.

La herramienta Identidad y acceso configuró su aplicación para que aceptara tokens procedentes del inquilino de Azure AD que se elija. Para ello, almacenó en caché en el archivo web.config las coordenadas de protocolo necesarias para conectar con los extremos de Azure AD a los que van dirigidas. Además, guardó información clave usada en el momento de autenticación para validar que el token de entrada se originó realmente desde el inquilino de Azure AD: esos son el nombre del emisor que representa el inquilino y la clave pública (en la forma de certificado X.509) que se debe usar para comprobar la firma del token.

Es una práctica de seguridad habitual renovar con regularidad claves criptográficas y las claves de firma de Azure AD no son ninguna excepción: en intervalos de tiempo fijos se retirarán las claves antiguas y las nuevas ocuparán su lugar en la lógica de firma del emisor y en el documento de metadatos de su inquilino. En caso de emergencia se puedan renovar las claves fuera de ciclo con poca o ninguna advertencia.

Cada vez que se revierte la clave de firma, se debe cambiar la configuración de la aplicación en consecuencia: siguiendo el enfoque mostrado en el tutorial hasta ahora, eso significaría la nueva ejecución de la herramienta para leer el nuevo documento de metadatos y actualizar las entradas de web.config.

Para minimizar el tiempo de inactividad, es una buena idea agregar la lógica de recuperación automática directamente en la aplicación de manera que pueda consumir el documento de metadatos mediante programación y reaccionar frente a la reversión de clave sin la necesidad de la intervención del operador. A continuación, encontrará un ejemplo de cómo implementar dicha característica.

  1. Use el Explorador de soluciones, como se describe anteriormente en el documento, para agregar una referencia al ensamblado System.IdentityModel.

  2. Agregue las siguientes directivas de uso al archivo Global.asax:

    using System.Configuration;
    using System.IdentityModel.Tokens;
    
    
  3. A continuación, agregue el siguiente método al archivo Global.asax:

    //...
    protected void RefreshValidationSettings()
    {
        string configPath = AppDomain.CurrentDomain.BaseDirectory + "\\" + "Web.config";
        string metadataAddress = 
                      ConfigurationManager.AppSettings["ida:FederationMetadataLocation"];
        ValidatingIssuerNameRegistry.WriteToConfig(metadataAddress, configPath);
    }
    
    
    La lógica aquí es muy sencilla. ValidatingIssuerNameRegistry es la clase usada por la herramienta Identidad y acceso para registrar información acerca de qué autoridades son de confianza y qué claves se deben usar para comprobar los tokens que emiten. WriteToConfig es un método estático que lee la configuración del emisor desde un documento de metadatos (en este caso recuperado desde el archivo config, donde se almacenó por la primera ejecución de la herramienta, por la segunda línea del método) y lo usa para crear o actualizar la sección config correspondiente del archivo en la ruta especificada (construida desde el AppDomain actual en la primera línea del método).

  4. Para insertar RefreshValidationSettings() en el ciclo de vida de la aplicación, invóquelo desde Application_Start() como se muestra a continuación.

    protected void Application_Start()
    {
        AreaRegistration.RegisterAllAreas();
    
        WebApiConfig.Register(GlobalConfiguration.Configuration);
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
        RefreshValidationSettings();
    }
    
    La llamada a RefreshValidationSettings desde Application_Start garantiza que el archivo web.config se modificará en un tiempo seguro, mientras que si lo hace posteriormente en el ciclo de vida de la aplicación, se arriesgaría a desencadenar una actualización.

ImportantImportante
Hay algunas precauciones adicionales que necesita aplicar cuando se actualizan de manera automática las claves de validación desde la aplicación. La principal amenaza que necesita mitigar es el secuestro de DNS, donde un atacante usa malware para señalarle a un documento de metadatos malintencionado e inducir a su aplicación para que confíe en las claves incorrectas.

Si no invalida los valores predeterminados de .NET para controlar las solicitudes HTTP, el escenario anterior ya está mitigado gracias al hecho de que los documentos de metadatos se hospedan en extremos HTTPS. Un secuestro DNS puede redirigir solicitudes a un extremo malintencionado pero dicho extremo no puede pasar la validación de servidor HTTPS: no teniendo como propiedad realmente el dominio en cuyos documentos de metadatos se hospedan, el atacante no puede obtener un certificado emitido para ello, de ahí que el cliente podrá detectar un problema con el servidor y evitar que se le dirija incorrectamente.

Ocasionalmente algunos escenarios de desarrollo requerirán que desactive la validación de HTTPS (normalmente mediante la clase ServicePoint). Si usa la lógica de actualización de metadatos automática mostrada en esta sección, es crítico restaurar la configuración de validación HTTPS antes de implementar la aplicación en producción.

  1. Ahora finalmente podemos observar la aplicación en acción. Presione F5: se abrirá una ventana del explorador, intentando acceder a la URL especificada en la configuración del proyecto en la sección "Crear una aplicación MVC”.

    En primer lugar, obtendrá un error de certificado. Este es un comportamiento esperado, haga clic en Pasar a este sitio web (no recomendado). No omita este error en una aplicación de producción aunque es aceptable para la finalidad de este tutorial.

    CertificateError Si continúa observando la barra de dirección, podrá ver por un breve momento la URL de la aplicación; sin embargo, el módulo FAM delante de la aplicación reconoce de inmediato la llamada como no autenticada, lee qué hacer desde el archivo de configuración y desencadena la redirección de inicio de sesión a Azure AD. La barra de dirección URL se reemplaza por la de la autoridad y al usuario se le solicita autenticar mediante la UI de Azure AD.

    noteNota
    La nueva cuenta de usuario que ha creado anteriormente no se puede usar para administrar su suscripción a Azure si ha iniciado sesión inicialmente en el Portal de administración mediante una cuenta Microsoft. Si intenta regresar al Portal de administración tras haber iniciado de sesión en la aplicación como el nuevo usuario, obtendrá un mensaje de error. En su lugar, debe iniciar sesión en el Portal de administración con la cuenta que ha usado para crear el inquilino de directorio. Si ha iniciado sesión inicialmente en el Portal de administración mediante una cuenta de Azure AD y si al nuevo usuario que creó anteriormente se le dio el rol de Administrador global, este nuevo usuario podrá administrar su suscripción a Azure.

    Iniciar sesión en AAD
  2. Introduzca las credenciales del usuario que ha creado en el inquilino de Azure en la primera sección del tutorial. Presione el botón Iniciar sesión.

    Puede que recuerde que cuando creó el usuario en su inquilino de Azure AD el Portal de administración le asignó una contraseña temporal. Tiene que autenticar con esa contraseña: sin embargo, dado que dicha contraseña estaba pensada para ser temporal, durante esta primera operación de inicio de sesión se le pedirá elegir una contraseña de usuario adecuada para poder avanzar con el flujo de autenticación. Una vez que haya terminado, se restaurará el flujo de inicio de sesión normal a la aplicación.

    Página principal de la aplicación Conforme tiene lugar la autenticación correcta, WIF procesa las notificaciones desde el token de autenticación de entrada, que a su vez se usan por el código para mostrar sencillo que hemos agregado en el controlador principal. Desde ahora puede navegar por el sitio sin necesidad de autenticar de nuevo: todo postback llevará la cookie de la sesión controlado por el módulo SAM.

  3. Para observar lo que ocurre cuando finaliza la sesión, haga clic en el vínculo para cerrar sesión de la esquina superior derecha. Observará las redirecciones que hemos codificado anteriormente, que eventualmente aparecerán en la vista siguiente.

    Cerrar sesión Para comprobar que realmente ha cerrado sesión, haga clic en cualquier otro elemento de la interfaz de usuario: el ciclo de la autenticación comenzará de nuevo.

La parte del tutorial del documento le mostró los pasos esenciales que tiene que llevar a cabo para agregar un inicio de sesión web en la aplicación web. El resto del documento irá más allá de los aspectos básicos, profundizando aún más en algunos temas clave y cubriendo algunas de las demás tareas que puede que necesite llevar a cabo para mover la aplicación al siguiente nivel.

En esta sección aprenderá cómo modificar la configuración de su aplicación para implementarla y ejecutarla en los Sitios web de Azure. La aplicación permanece en gran medida sin cambiar: los únicos asuntos que requieren atención son la acomodación de la nueva dirección y administración de sesiones de su aplicación.

Esta parte del documento requiere que tenga un sitio web de Azure como destino para la implementación de su aplicación. Si ya tiene un sitio web disponible, puede usarlo; de no ser así, consulte este documento para obtener información acerca de cómo crear y publicar un sitio web de Azure. Si sigue el tutorial en ese documento, deténgase justo después de haber descargado el perfil de publicación: hay un par de cuestiones que necesitamos ajustar antes de implementar la aplicación.

Ajustar la configuración de la aplicación en el Portal de administración de Azure

Si recuerda la sección acerca del registro de la aplicación, recordará que un parámetro clave que defina su aplicación en la interfaz de usuario de Azure AD es la URL de la propia aplicación. Los pasos del tutorial hasta ahora suponen que el IIS local se expresa como la ubicación de la aplicación. Sin embargo, una implementación en Sitios web de Azure significa que la URL de la aplicación cambiará y que la configuración en Azure AD tendrá que reflejarlo.

  1. Regrese al Portal de administración, seleccione la pestaña Active Directory de la izquierda, haga clic en el inquilino de directorio, elija el encabezado Aplicaciones, haga clic en la entrada correspondiente a la aplicación con la que ha estado trabajando. Haga clic en el encabezado Configurar; se desplazará a una pantalla que le permitirá modificar la configuración de la aplicación que ha introducido en el momento de la creación. Para este tutorial, omita las áreas principales de la pantalla y desplácese a la sección de inicio de sesión único.

    Inicio de sesión único
  2. Encuentre el cuadro de texto REPLY URL e introduzca allí la dirección de su sitio web de Azure de destino (por ejemplo, https://aadga.windowsazure.net/https://aadga.windowsazure.net/). Eso permitirá a Azure AD devolver tokens a su ubicación de sitio web de Azure tras una autenticación correcta (frente a la ubicación de hora de desarrollo que ha usado anteriormente en el subproceso). Una vez actualizado el valor, pulse GUARDAR en la barra de comandos de la parte inferior de la pantalla.

noteNota
Puede que haya observado que el APP ID URI todavía está usando el valor basado en localhost que ha creado anteriormente en el documento.

Técnicamente, siempre que el identificador esté en formato URI y sea único en todas las aplicaciones del inquilino de directorio actual, para el tipo de aplicaciones tratada aquí, funcionará cualquier valor; por este motivo las instrucciones principales no incluyen la actualización de ese valor.

Sin embargo, para fines de facilidad de uso puede que desee modificar el APP ID URI para llevar un valor que sea más representativo de su aplicación. Un ejemplo típico sería alguno que se derive del valor de URL de respuesta.

Tenga en cuenta que, si cambia el valor de APP ID URI, tendrá que aplicar cambios más extensivos a la aplicación antes de implementar. Encontrará más detalles posteriormente.

Preparar la aplicación para su ejecución en sitios web de Azure

La configuración de inicio de sesión web está en su mayor parte lista para la nube: solo hay un cambio que necesita aplicar, en su mayor parte debido a las características de los sitios web de Azure.

El proceso de inicio de sesión web tiene como resultado la creación de una cookie de sesión, que se envía en cada solicitud desde el instante de la autenticación. La cookie de la sesión se crea por el middleware de WIF, y de manera predeterminada se firma y se cifra mediante DPAPI (vea este documento para información de fondo) a fin de evitar abusos desde el cliente (como el cambio de la lista de notificaciones para elevar privilegios). Sin embargo, la configuración de IIS en los sitios web de Azure evita el uso de DPAPI para proteger sesiones, de ahí que tenga que cambiar la manera en que WIF protege la cookie asociada. .NET Framework 4.5 ofrece una alternativa lista para usar, que aprovecha MachineKey (vea la documentación aquí) y funciona sin problemas en los sitios web de Azure.

La herramienta Identidad y acceso facilita en gran medida este cambio.

  1. Haga clic con el botón secundario del proyecto en el Explorador de soluciones, elija Identidad y acceso… y seleccione la pestaña Configuración. Verá algo parecido a lo que aparece en la siguiente captura de pantalla:

    Sitios web de identidad y acceso de Windows Azure
  2. Solo tiene que activar la marca Habilitar cookies listas para granja de servidores web y presionar Aceptar. La herramienta se encargará de agregar los elementos necesarios en web.config (en la práctica, sustituya la clase predeterminada SessionSecurityTokenHandler por MachineKeySessionSecurityTokenHandler) para cambiar a MachineKey como método de protección de cookies.

    noteNota
    Si en el paso anterior ha cambiado el APP ID URI en el Portal de administración de Azure, puede usar esta UI para aplicar fácilmente dichos cambios a su proyecto: solo tiene que pegar el valor del APP ID URI en los dos campos de texto superiores y pulsar Aceptar. La herramienta aplicará dichos cambios en los lugares correctos del archivo config.

    De manera opcional, puede que desee considerar de manera temporal el apagado de la mensajería de errores personalizados, agregando la entrada <customErrors mode="Off" /> en la sección <system.web> del archivo web.config. Eso le ayudará a resolver problemas en caso de que se encuentre con problemas a la hora de la implementación. Sin embargo, asegúrese de que vuelve a activarlos antes de pasar a producción: los atacantes pueden utilizar los mensajes de error detallados para investigar su aplicación para aperturas y customError evitará que eso suceda.

Eso es todo lo que necesita hacer para preparar su aplicación para que se ejecute como sitio web de Azure. Use la configuración de publicación para implementar la aplicación. A continuación, abra un explorador, navegue hasta la dirección azurewebsite.net de su aplicación y siga el mismo flujo que se trata en la sección de prueba de la aplicación del tutorial: dado que diseñamos toda la lógica personalizada para que sea independiente de la ubicación, podrá llevar a cabo las mismas operaciones que ha probado de manera local.

La herramienta Identidad y acceso genera automáticamente los valores de configuración que son necesarios para que su configuración se integre con su inquilino de Azure AD mediante WS-Federation. En el mejor de los casos, nunca tendrá que ver esta configuración; sin embargo, hay ocasiones en las que desea alterar el comportamiento predeterminado o tiene que solucionar un problema. En esos casos, puede resultar de utilidad encontrar su camino a través de los ajustes de configuración de WIF.

El método y las clases de WIF usados en el flujo de inicio de sesión web se documentan por completo en MSDN; aquí presentaremos una versión anotada del archivo web.config una vez que lo ha modificado la herramienta Identidad y acceso. Para su comodidad, también hemos incluido los cambios derivados de la sección sobre publicación en sitios web de Azure.

noteNota
Por motivos de claridad, el documento incluye el origen de Web.config completo. Sin embargo, solo se anotan las secciones relevantes para WIF.

<?xml version="1.0" encoding="utf-8"?>
<!--
  For more information on how to configure your ASP.NET application, please visit
  http://go.microsoft.com/fwlink/?LinkId=169433
  -->
<configuration>
  <configSections>
    <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />

Sin comentarios para la configuración anterior.

<section name="system.identityModel" type="System.IdentityModel.Configuration.SystemIdentityModelSection, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
    <section name="system.identityModel.services" type="System.IdentityModel.Services.Configuration.SystemIdentityModelServicesSection, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />

En la configuración anterior, esta área carga las clases que ASP.NET necesita para leer e interpretar las secciones de configuración usadas por WIF para modelar el flujo de WS-Federation y la configuración de autenticación.

  </configSections>
  <appSettings>
    <add key="webpages:Version" value="2.0.0.0" />
    <add key="webpages:Enabled" value="false" />
    <add key="PreserveLoginUrl" value="true" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />

Sin comentarios para la configuración anterior.

    <add key="ida:FederationMetadataLocation" value="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/federationmetadata/2007-06/federationmetadata.xml" />
    <add key="ida:Issuer" value="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/wsfed" />
    <add key="ida:ProviderSelection" value="productionSTS" />
  </appSettings>

Para la configuración anterior, dichas entradas de appSettings se capturan por la herramienta Identidad y acceso, para realizar un seguimiento de configuración importante (como la dirección del documento de metadatos, que hemos usado en la sección de sustitución de clave) que no se guardaría en otro lugar.

  <location path="FederationMetadata">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>
  <location path="SignOut">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>

Para la configuración anterior, esos dos elementos de <location> graban dos áreas en la aplicación web a las que se puede acceder sin requisitos de autenticación (vea a continuación). La sección FederationMetadata se crea por la herramienta Identidad y acceso: la herramienta crea un documento de metadatos que describe la aplicación, que se puede utilizar por las autoridades para aprovisionar la aplicación. Ha agregado la sección SignOut usted mismo como parte de las instrucciones sobre cómo implementar el cierre de sesión web.

  <system.web>
    <authentication mode="None" />
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" requestValidationMode="4.5" />
    <!--Commented by Identity and Access VS Package-->
    <!--<authentication mode="Windows" />-->
    <authorization>
      <deny users="?" />
    </authorization>

Para la configuración anterior, de manera predeterminada, la herramienta Identidad y acceso establece la configuración de autenticación y autorización de ASP.NET de manera que todas las partes de la aplicación web (salvo las excepciones anteriores) requieren que se autentiquen los usuarios antes de servir las solicitudes. Aunque eso suele ser adecuado para las aplicaciones LoB, a veces los desarrolladores desean conservar áreas a las que se pueden acceder de manera anónima: si ese es el caso para usted, cambie la configuración aquí de manera adecuada.

    <pages>
      <namespaces>
        <add namespace="System.Web.Helpers" />
        <add namespace="System.Web.Mvc" />
        <add namespace="System.Web.Mvc.Ajax" />
        <add namespace="System.Web.Mvc.Html" />
        <add namespace="System.Web.Optimization" />
        <add namespace="System.Web.Routing" />
        <add namespace="System.Web.WebPages" />
      </namespaces>
    </pages>
    <customErrors mode="Off" />
    <machineKey decryptionKey="998D0533DD570FDCA86A945893F0B2BFC0E1F3645E148F35" validationKey="E739C2EA4B4470820308DA71D81160F22C0D9CD3C97709CB0679E55FDCC2D35B35563D56102F254FB4908644ECB53B3898948F54AAC4A5F0C44754A5A997B79A" />
  </system.web>
  <system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <handlers>
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>

Sin comentarios para la configuración anterior.

    <modules>
      <remove name="FormsAuthentication" />
      <add name="WSFederationAuthenticationModule" type="System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
      <add name="SessionAuthenticationModule" type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
    </modules>
  </system.webServer>

Para la configuración anterior, las entradas de esta sección insertan en la canalización de SP.NET los HTTPModules que implementan el protocolo principal y las características de control de sesiones. El WSFederationAuthenticationModule (FAM) fuerza WS-Federation, validando los tokens de entrada y generando mensajes de inicio de sesión a la autoridad según las especificaciones del protocolo. El SessionAuthenticationModule (SAM) crea y valida cookies de sesión, junto con el FAM.

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-1.3.0.0" newVersion="1.3.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
  <entityFramework>
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
      <parameters>
        <parameter value="v11.0" />
      </parameters>
    </defaultConnectionFactory>
  </entityFramework>

Sin comentarios para la configuración anterior.

  <system.identityModel>
    <identityConfiguration>
      <audienceUris>
        <add value="https://localhost:44342/ShiungZZZ" />
      </audienceUris>

Para la configuración anterior, <system.identityModel> ajusta toda la configuración específica de clases WIF. Su primer elemento secundario, IdentityConfiguration, proporciona una descripción independiente de protocolo del comportamiento de la aplicación. La lista AudienceUris proporciona todos los valores que WIF considerará como ámbitos aceptables en los tokens de entrada para las aplicaciones actuales; normalmente se corresponden con el territorio de la aplicación (o APP ID URI, en términos de Azure AD). Un token de entrada debe declarar que su destinatario previsto es uno de los valores mostrados aquí; si ese no es el caso, WIF asumirá que este es un token robado y rechazará la llamada.

           
      <issuerNameRegistry type="System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, System.IdentityModel.Tokens.ValidatingIssuerNameRegistry">
        <authority name="https://sts.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/">
          <keys>
            <add thumbprint="3A38FA984E8560F19AADC9F86FE9594BB6AD049B" />
          </keys>
          <validIssuers>
            <add name="https://sts.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/" />
          </validIssuers>
        </authority>
      </issuerNameRegistry>

Para la configuración anterior, el elemento ValidatingIssuerNameRegistry contiene la lista de las tuplas de clave de firma de nombre de emisor aceptables. En este tutorial, la configuración reflejará los valores asociados a su inquilino de Azure AD: este elemento garantiza que ningún otro emisor, incluidos otros inquilinos de Azure AD propiedad de otras compañías, puede obtener acceso a su aplicación.

<certificateValidation certificateValidationMode="None">
      </certificateValidation>

Para la configuración anterior, este elemento desactiva la validación de certificado en la canalización de WIF. Esta medida es necesaria en el caso de Azure AD, dado que se usa un certificado autofirmado: aparte de instalar el propio certificado en el almacén de certificados local, una cadena o una validación de par fallaría. Tenga en cuenta: esto no disminuye realmente la seguridad para la autenticación de Azure AD, dado que el ValidatingIssuerNameRegistry garantiza que se usará el certificado correcto; si está usando WIF en la misma aplicación para confiar en otros emisores, le advertimos que dicha configuración también se extendería a ellos.

      <securityTokenHandlers>
        <add type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
        <remove type="System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
      </securityTokenHandlers>
    </identityConfiguration>

Esta sección le permite manipular la colección de clases que WIF usa para procesar tokens de seguridad de entrada (los denominados controladores de tokens). Se puede usar para influir en el comportamiento de controladores individuales o para agregar y quitar tipos de controladores. En este caso, la herramienta eliminó el controlador de sesión predeterminado (que se basa en DPAPI y no puede funcionar en Sitios web de Azure) y lo sustituye por uno que funciona con la MachineKey.

  </system.identityModel>
  <system.identityModel.services>
    <federationConfiguration>
      <cookieHandler requireSsl="false" />
      <wsFederation passiveRedirectEnabled="true" issuer="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/wsfed" realm="https://localhost:44342/ExpenseReport" requireHttps="false" />
    </federationConfiguration>
  </system.identityModel.services>
</configuration>

Para la configuración anterior, <system.identityModel.services> se usa para almacenar coordenadas específicas de WS-Federation.

El elemento wsFederation, en concreto, se usa aquí para grabar el extremo de inicio de sesión de WS-Federation de su inquilino de Azure AD; el territorio (APP ID URI) de la aplicación, para enviarse como identificador en el momento del inicio de sesión; y otras marcas que influyen en el comportamiento local de WIF, como si los errores 401 de la aplicación deberían desencadenar siempre un mensaje de inicio de sesión a la autoridad (passiveRedirectEnabled) o si se deben permitir transacciones en HTTP limpia.

Este elemento se puede usar para especificar muchos más parámetros de protocolo: esos son solo el mínimo absoluto para que funcione el flujo de inicio de sesión.

Este documento se centra en una tarea bastante estrecha, conectando una aplicación .NET con Azure AD para llevar a cabo el inicio de sesión web mediante WS-Federation. Hay muchos más escenarios que puede abordar, usando una variedad de protocolos abiertos diferentes, aprovechando cualquier pila de programación en cualquier plataforma moderna o trabajando directamente en el nivel de protocolo en el cable.

En la sección acerca de la implementación de la aplicación en Azure, vio que el Portal de administración le ofrece la oportunidad de cambiar muchos más aspectos de la configuración de registro de la aplicación: conocerá la mayoría de esos controles adicionales en el siguiente tutorial de la serie. Aquí solo mencionaremos brevemente cómo puede obtener la información que necesita en el caso de que elija interactuar con Azure AD en el nivel de protocolo, para inicio de sesión web o cualquier otro de los flujos que admita.

  1. Abra el Portal de administración de Windows Azure en una ventana del explorador y navegue hasta el encabezado Aplicaciones de la sección de Azure AD. Observará que la barra de comandos de la parte inferior de la pantalla contiene una entrada: Ver extremos. Haga clic en ella.

    Extremos de la aplicación El diálogo muestra todos los extremos que puede usar para interactuar con su inquilino de Azure AD mediante programación. Esta es una breve explicación de todas las entradas:

    • Documento de metadatos de federación: La ubicación del documento de metadatos que describe el inquilino de Azure AD como autoridad de inicio de sesión web. Como se ha visto en el tutorial, en la sección acerca de la actualización automática de claves, este documento contiene coordenadas de metadatos de WS-Federation; también contiene los metadatos del protocolo SAML en el mismo paquete. Para obtener más información, vea Federation Metadata.

    • Extremo de inicio de sesión de WS-Federation: el punto de entrada para todas las transacciones de WS-Federation. Este es el extremo que ha usado en el tutorial para flujos de inicio y de cierre de sesión. Para obtener más información, vea WS-Federation Endpoint URL.

    • Extremo de inicio de sesión de SAML-P: El extremo usado para implementar flujos de inicio de sesión en el protocolo SAML. Para obtener más información, vea SAML Protocol Metadata and Endpoints.

    • Extremo de cierre de sesión de SAML-P: el extremo usado para implementar flujos de cierre de sesión en el protocolo SAML. Para obtener más información, vea SAML Protocol Metadata and Endpoints.

    • Extremo de Azure AD Graph: las consultas para recuperar información de directorio almacenada en el inquilino de Azure AD actual se deben dirigir a este extremo, usando la sintaxis de la API de Graph. Para obtener más detalles, vea Uso de la API Graph para realizar consultas a Azure AD.

    • Extremo de token de OAuth2: este extremo se usa para flujos de autenticación de servidor a servidor: por ejemplo, se puede usar para obtener tokens de acceso para invocar el extremo de Graph. Para obtener más información, vea OAuth 2.0 (Preview Version).

¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios

Adiciones de comunidad

Mostrar:
© 2014 Microsoft