ASP.NET Web API
ASP.NET Web API segura con Windows Azure AD y los componentes de Microsoft OWIN
A medida que el papel de Web API se vuelve más prominente, también lo hace la necesidad de garantizar que podamos usarla con confianza en situaciones de mucho valor agregado, donde existe el riesgo de una exposición de datos y operaciones confidenciales.
La industria está convergiendo claramente en una solución para la protección de REST API: la norma OAuth 2.0. En la práctica, sin embargo, esta no ofrece instrucciones detalladas sobre lo que se debe hacer en el nivel de proyecto. Además, las clases y herramientas existentes en Microsoft .NET Framework para proteger las comunicaciones se diseñaron para que funcionaran con ciertos tipos de aplicaciones determinadas (aplicaciones con una experiencia de usuario web basada en el postback). No se prestan bien para las Web API y las situaciones con varios clientes que estas hacen posible. Como resultado de esto, hasta ahora la protección de una Web API ha sido una actividad bastante artesanal. No necesariamente insegura, pero con muchas variaciones entre una solución y otra y que requiere de una cantidad demasiado grande código personalizado.
Con el lanzamiento de Visual Studio 2013, podemos dejar todo esto atrás. Esta edición introduce innovadoras herramientas ASP.NET y middleware de seguridad de los componentes de Microsoft Open Web Interface for .NET (OWIN) que permiten proteger sin problemas las Web API. Las nuevas plantillas y herramientas de ASP.NET permiten configurar un proyecto Web API para externalizar la autenticación directamente a Windows Azure Active Directory (AD), al emitir el código necesario en el proyecto local y en las entradas correspondientes en Windows Azure AD.
En este artículo mostraré cómo aprovechar estas características nuevas de Visual Studio 2013 para crear una Web API sencilla, protegida por Windows Azure AD. También mostraré cómo crear un cliente de prueba para que veamos la API en pleno funcionamiento. También echo una mirada breve a lo que ocurre tras bambalinas, lo que sirve como punto de partida si necesitamos profundizar más y explorar los aspectos más avanzados de esta situación.
Credenciales, por favor
En resumidas cuentas, la autenticación consiste en pedirle al autor de la llamada, cuando se envía un mensaje a un servidor, que incluya algún tipo de credencial que permita certificar su identidad o recuperar sus atributos. El servidor luego emplea esta información para la autorización: determinar si se le otorga acceso o no y en qué términos.
Con frecuencia, los recursos externalizan la mayor parte de las funciones de autenticación en un proveedor de servicios independiente, conocido comúnmente como una autoridad o proveedor de identidad. Estos proveedores se encargan de las tareas pesadas como la incorporación de usuarios, la asignación de credenciales, el procesamiento de los flujos de ciclo de vida (como la recuperación de contraseñas), el proporcionar una interfaz de usuario para la autenticación de los usuarios, la validación de las credenciales mediante diferentes protocolos, la administración de la autenticación multifactor, la detección de fraudes, entre otras cosas.
Una vez resueltas estas funciones, la única tarea de autenticación necesaria es comprobar que la autenticación funcione en la autoridad elegida. Esto generalmente implica examinar un token de seguridad, un fragmento de datos que una autoridad emite para un autor de llamada si la autenticación se completó correctamente.
Los tokens de seguridad generalmente se confeccionan en conformidad con un formato específico, se firman digitalmente con una clave que identifica en forma inequívoca a la autoridad emisora y contienen datos que vinculan el token de manera unívoca con el recurso de destino. Cuando el recurso recibe una solicitud, busca el token adjunto. Si encuentra uno que cumpla con los atributos de validación requeridos, se autentica al autor de la llamada.
A esta escala, el patrón es tan genérico que podría describir diferentes tipos de autenticación. Para aplicarlo en esta situación, asignaré los roles de alto nivel a entidades concretas.
El recurso El recurso será el proyecto ASP.NET Web API 2 que debo proteger. Podemos aplicar requisitos de autenticación con un nivel de precisión mayor. Por ejemplo, podemos definir que solo se protegerá un subconjunto de las acciones y las demás aceptarán autores de llamada anónimos.
La autoridad Configuraré Web API para que externalice las operaciones de autenticación a Windows Azure AD, una plataforma como servicio (PaaS) disponible para todos los suscriptores de Windows Azure. Windows Azure AD se diseñó específicamente para que funcionara con cargas de trabajo de aplicaciones basadas en la nube. El servicio almacena información sobre los usuarios (atributos y credenciales), además de la estructura de la organización. Usted puede sincronizar sus datos con su Windows Server Active Directory, si lo desea, o residir exclusivamente en la nube, sin necesidad de ninguna instalación local.
Casi todos los servicios en línea de Microsoft (Office 365, Intune y Windows Azure) emplean Windows Azure AD para las funciones de autenticación y directorios. Gracias a las normas abiertas y los protocolos comunes, podemos conectarnos a Windows Azure AD desde prácticamente cualquier aplicación (Web UX, Web API, cliente nativo, servidor a servidor, etcétera) y plataforma. Demostraré cómo registrar una aplicación en Windows Azure AD y hacer uso de sus extremos OAuth 2.0.
Formato y validación del token La especificación OAuth 2.0 no prescribe ningún formato de token en concreto, pero el formato JSON Web Token (JWT, bit.ly/14EhlE8) se ha convertido en la norma de facto en los casos con REST. Tanto Windows Azure AD como los componentes de Microsoft OWIN son compatibles con el formato JWT en los flujos OAuth 2.0. Hago mención de esto principalmente para entregar un poco de contexto. La mecánica de la adquisición y validación de JWT queda en manos del middleware, y el formato del token es transparente para el código de la aplicación.
El cliente Cuando un recurso se vale de una autoridad para la autenticación, de hecho queda desacoplado del cliente. La forma en que el usuario (y la aplicación cliente) obtiene un token se convierte en un asunto entre el usuario y la autoridad. Esto es excelente para la facilidad de mantenimiento del código, pero si queremos ver nuestra API en marcha, igual debemos configurar un cliente. Aprenderá cómo puede registrar un cliente nativo para Web API en Windows Azure AD y cómo usar AD Authentication Library (ADAL) de Windows Azure para permitir que una aplicación cliente .NET sofisticada autentique a los usuarios frente a Windows Azure AD y obtenga los tokens para proteger las llamadas a Web API.
En la figura 1 se ilustran los diferentes elementos de la solución que voy a crear. No se preocupe si todavía no entiende algunas etiquetas: todo se explicará a medida que desarrollemos la solución.
.png)
Figura 1 Arquitectura de la solución de extremo a extremo
Creación del proyecto Web API
Para crear el proyecto Web API, use las nuevas herramientas y plantillas de ASP.NET en Visual Studio 2013. Abra Visual Studio y cree un nuevo proyecto Aplicación web ASP.NET. En el cuadro de diálogo de proyecto nuevo, seleccione la plantilla Web API. Haga clic en el botón Cambiar autenticación.
Aparecerán los estilos de autenticación disponibles en forma nativa para una Web API, tal como se aprecia en la figura 2. Elija Cuentas organizacionales, lo que permite usar Windows Azure AD como la autoridad. (Para obtener más información sobre todas estas opciones, consulte bit.ly/1bhWngl.) El objetivo aquí es recopilar información sobre las características de la Web API que son importantes desde el punto de vista de la administración de identidades y determinar qué instancia de Windows Azure AD (conocida generalmente como un “inquilino”) debemos configurar para que se encargue de la autenticación.
.png)
Figura 2 Cuadro de diálogo Cuentas organizacionales
La primera lista desplegable determina si solo un inquilino de Windows Azure AD (lo que ocurre por lo general en una aplicación de línea de negocio) o varios inquilinos Windows Azure AD (lo que cabría esperar en una aplicación de software como servicio [SaaS]) debe usar la aplicación. Normalmente seleccionamos Una organización si los empleados de la empresa van a usar la aplicación y Varias organizaciones si a la aplicación accederán los usuarios de varias empresas. Sin embargo, estas alternativas actualmente solo están disponibles para las aplicaciones ASP.NET Web Forms y ASP.NET MVC. Por el momento, la plantilla de proyecto Web API solo admite la opción Una organización.
El cuadro de texto Dominio identifica qué inquilino de Windows Azure AD debe registrar la aplicación. Generalmente se trata del directorio empresarial asociado con la suscripción a Windows Azure, pero también sirve cualquier directorio para el cual tengamos credenciales de administración (ya volveremos sobre este punto). En el momento de la creación, cada inquilino de Windows Azure AD tiene asociado un dominio de tres niveles con el formato su-organización.onmicrosoft.com. Generalmente asociaremos el inquilino a uno o más dominios que ya tenemos. En el ejemplo de la figura 2 uso mi propio dominio, cloudidentity.net.
La lista desplegable Nivel de acceso especifica qué derechos de acceso debe tener la aplicación con respecto al directorio. El valor predeterminado, Inicio de sesión único, permite que el directorio emita tokens para la aplicación. Esto es un reconocimiento simple de que la aplicación está registrada. La autoridad no emitirá tokens para aplicaciones que no estén registradas, aunque la autenticación se haya completado correctamente.
Otros niveles de acceso son “Leer datos del directorio” y “Leer y escribir datos del directorio”, que permiten que la aplicación consulte y modifique, respectivamente, el directorio y su contenido. Hace esto a través de Graph API, una interfaz programática basada en REST diseñada para otorgar acceso delegado a las aplicaciones de cualquier plataforma con una pila HTTP al directorio. Me quedaré con el nivel de acceso predeterminado de Inicio de sesión único y no demostraré Graph en el proyecto Web API. Se trata, sin embargo, de una función extremadamente poderosa de Windows Azure AD. Para obtener más información sobre Graph API de Windows Azure AD , consulte bit.ly/1aByRLS.
Después de escribir el dominio asociado con su inquilino Windows Azure AD, haga clic en Aceptar para generar el proyecto. La herramienta llevará a cabo dos tareas:
- Se pondrá en contacto con el inquilino de Windows Azure AD seleccionado y agregará una entrada que describe la aplicación que se está creando.
- Emitirá el código para un proyecto Web API, agregará el middleware de seguridad necesario de los componentes de Microsoft OWIN para que se haga cargo de la autenticación de Windows Azure AD y generará el código de inicialización necesario para validar los tokens entrantes en función del inquilino de Windows Azure AD elegido.
La primera tarea se realiza mediante Graph API (Visual Studio mismo es un cliente de Graph API). Para agregar la entrada que describe la aplicación que estamos creando al directorio, esta debe obtener un token del directorio para demostrar que contamos con privilegios de escritura en el directorio. Por esta razón, cuando hacemos clic en Aceptar, Visual Studio presenta el aviso de autenticación que se muestra en la figura 3.
.png)
Figura 3 Aviso de autenticación de inicio de sesión en cuenta
Todo lo que tiene que hacer ahora es escribir las credenciales de administrador para el directorio. La herramienta comprueba que tiene los privilegios necesarios para llevar a cabo las operaciones requeridas. Cuando hace clic en Aceptar, Visual Studio se pone en contacto con Windows Azure AD y crea los archivos de proyecto.
Ahora tenemos una Web API configurada completamente, lista para hacer valer que solo los autores de llamada del inquilino de Windows Azure AD especificado obtengan acceso. Veámoslo con más detención.
Vaya al panel Explorador de soluciones, donde en la raíz aparece un archivo llamado Startup.cs. Si leyó el artículo “Introducción al proyecto Katana” de Howard Dierking de la edición del mes pasado (msdn.microsoft.com/magazine/dn451439), ya sabe que la clase en este archivo se llama cuando se inicia la aplicación. En este caso, la implementación es sencilla:
public partial class Startup
{
public void Configuration(IAppBuilder app)
{
ConfigureAuth(app);
}
}
Como es corriente, esperaríamos que el método ConfigureAuth esté definido en alguna clase bajo la carpeta de solución App_Start. De hecho, es el archivo Startup.Auth.cs. Este es el código:
public partial class Startup
{
public void ConfigureAuth(IAppBuilder app)
{
app.UseWindowsAzureActiveDirectoryBearerAuthentication(
new WindowsAzureActiveDirectoryBearerAuthenticationOptions
{
Audience = ConfigurationManager.AppSettings["ida:Audience"],
Tenant = ConfigurationManager.AppSettings["ida:Tenant"]
});
}
}
La convención de nomenclatura app.Use* sugiere que el método agrega una implementación en middleware a la canalización de OWIN. En este caso, el middleware adicional examina las solicitudes entrantes para ver si el encabezado Authorization de HTTP contiene un token de seguridad. Así es como se protege una solicitud según la especificación del token portador de OAuth 2.0 (ver bit.ly/W4OqA3). Si encuentra un token, este se valida mediante varias pruebas corrientes: ¿El token fue emitido por la autoridad prevista? ¿Fue modificado durante el tránsito? ¿Expiró?
Si el token se ve bien, el middleware proyecta su contenido en una entidad de seguridad, asigna esta al usuario actual y cede el control al siguiente elemento de la canalización. Si el token no aprueba los controles, el middleware envía de vuelta el código de error pertinente.
Si no hay ningún token, el middleware simplemente deja pasar la llamada sin crear ninguna entidad de seguridad. La lógica de autorización, generalmente en la forma de filtros de autorización, usa la presencia o ausencia de una entidad de seguridad (y su contenido) para decidir si la solicitud se debe atender o si se debe denegar el acceso.
El parámetro único que se pasa al middleware, WindowsAzureActiveDirectoryBearerAuthenticationOptions, proporciona los valores de configuración necesarios para determinar la validez de un token. Captura los valores sin procesar durante la creación del proyecto y los almacena en el archivo web.config. El valor de Audience es el identificador por el cual Windows Azure AD reconoce a Web API. Cualquier token que tenga un valor diferente de Audience está destinado a otro recurso y se debe rechazar.
La propiedad Tenant indica qué inquilino de Windows Azure AD se debe usar para externalizar la autenticación. El middleware usa esta información para acceder al inquilino y leer todas las demás propiedades (p. ej. qué claves se deben usar para validar las firmas del token) que determinan la validez de un token.
Estas pocas líneas de código autogenerado son todo lo que hace falta para autenticar a los autores de llamada con Windows Azure AD. Lo único que queda por hacer en el proyecto Web API es decorar con [Authorize] los métodos que queremos proteger. Agréguelo para todos los métodos en ValuesController. (Para simplificar, trabajo con los controladores predeterminados que vienen con la plantilla.)
Ahora, ¿cómo comprobamos que Web API se comporta según lo previsto? La forma más sencilla es crear un cliente de prueba.
Registro de un cliente nativo
Así como Windows Azure AD no emitirá tokens para las Web API que no estén registradas, Windows Azure exige que todos los clientes que soliciten tokens también estén registrados. Para obtener un token para una Web API específica, un cliente registrado también debe haber recibido el acceso explícitamente a esa Web API en Windows Azure AD. Estas configuraciones que pertenecen al diseño deben estar listas antes de que cualquier usuario trate de autenticarse. Ahora mostraré cómo usar el portal de Windows Azure para registrar una aplicación cliente y crear el permiso que la enlaza con la Web API que creamos.
Comience por obtener acceso al portal de Windows Azure. Autenticaré la misma cuenta que usé previamente. Para ahorrar tiempo, navegaré directamente al portal de Windows Azure para mi inquilino de Windows Azure AD. Obtenemos esa URL al agregar el dominio del inquilino a la dirección del portal usual, en mi caso https://manage.windowsazure.com/cloudidentity.net.
Navegar a la URL propia del inquilino resulta más rápido que buscar el cuadro “Iniciar sesión con la cuenta organizacional” en la página de inicio de sesión general. Observe que si el Windows Azure AD con el que trabajamos no es administrador ni coadministrador de la suscripción a Windows Azure, entonces deberemos iniciar sesión en el portal mediante las credenciales usuales (una cuenta Microsoft u otra entidad organizacional).
Una vez que se carga el portal, seleccione el icono de Active Directory en la lista de los servicios disponibles, haga clic en su directorio y luego en la pestaña Aplicaciones. Aparecerá un listado de todas las aplicaciones que creó, inclusive la entrada del nuevo proyecto Web API. Para crear una entrada nueva, haga clic en el botón Agregar en la barra de comandos en la parte inferior de la página. Aparecerá el cuadro de diálogo que se muestra en la figura 4. Técnicamente, podría definir cualquier tipo de aplicación que sea un cliente válido para la Web API. Elija una aplicación cliente nativa y pase a la siguiente pantalla.
.png)
Figura 4 Primer paso del asistente Agregar aplicación en el portal de Windows Azure Active Directory
La siguiente y última pantalla pide una URI de redirección para la aplicación. Esta URI es simplemente un identificador que se usa durante el flujo de adquisición del token de OAuth 2.0 para señalar al autor de la llamada que terminó la parte interactiva del proceso de autenticación. La parte restante del proceso de adquisición del token se desarrollará sin interacción con el usuario. Según la plataforma en la que desarrollamos el cliente nativo, podríamos tener que enfrentarnos a diferentes restricciones. Por ejemplo, una aplicación para la Tienda Windows podría exigir que usemos el esquema ms-app:// protocol si queremos usar ciertas funciones (consulte la información detallada en bit.ly/13KrM6i).
En este caso, escribiré una aplicación .NET para escritorio clásica, que resulta ser muy poco demandante. Cualquier URI válida servirá. Usé https://cloudidentity.net/myWebAPItestclient para no olvidar la finalidad de este cliente.
En cuanto finalizo la entrada de la aplicación, aparece la página que se muestra en la figura 5.
.png)
Figura 5 Página de inicio rápido
La sección Actualice su código proporciona información que necesitaremos cuando escribamos la aplicación cliente. Incluye los valores para la URI de redirección y el identificador del cliente (un identificador simple), que luego vamos a necesitar cuando confeccionemos una solicitud de token a la autoridad.
La sección Configurar acceso a las Web API ofrece un vínculo a aquella parte del portal donde se especifica la API a la que debe tener acceso el cliente. Si sigue el vínculo, aterrizará en la página de propiedades de la aplicación que se muestra en la figura 6. Al fondo se aprecia una lista desplegable que permite especificar la Web API a la que desea que el cliente tenga acceso. Observe que aparecen tanto las aplicaciones que definimos nosotros como las API integradas, específicamente Graph API de Windows Azure AD.
.png)
Figura 6 Página de propiedades de la aplicación cliente nativa en el portal de Windows Azure Active Directory
Elija la entrada del proyecto Web API y presione Guardar. Con esto, todo está listo en Windows Azure AD para que un cliente obtenga tokens para nuestro servicio. Deje el explorador abierto con esa página, ya que luego necesitará algunos datos que aparecerán.
Creación de un proyecto de cliente sencillo y pruebas para la Web API
Finalmente estamos listos para crear un cliente de prueba y dar una vuelta por la Web API autenticada. Podemos crear prácticamente cualquier tipo de cliente, en cualquier plataforma que ofrezca una pila HTTP. Para simplificar la tarea de obtención y administración de los tokens, Microsoft ofrece ADAL, que simplifica la autenticación con Active Directory (tanto en Windows Azure como en Windows Server) sin necesidad de ser un experto en protocolos de autenticación.
La biblioteca para Microsoft .NET Framework ya se lanzó y se encuentra en condición de vista previa para desarrolladores en la Tienda Windows. (Para ver un tutorial sobre cómo implementar este caso con una aplicación para la Tienda Windows, consulte bit.ly/17YtYVg.) Con el tiempo, se proporcionarán diferentes versiones destinadas a todas las principales plataformas cliente.
Como la versión para .NET ya está disponible para el público general, usaré esta. Aparte de algunas diferencias sintácticas en las diferentes pilas, lo que aprenda aquí le servirá directamente en las otras plataformas y tipos de aplicaciones. Si no puede esperar, tenga en cuenta que todas las comunicaciones en el caso descrito se rigen por normas abiertas y están documentadas en todo detalle. Puede codificar la lógica de la solicitud de los tokens con gran facilidad. Para ver un ejemplo con Windows Phone 8, consulte bit.ly/YatATk.
El proyecto es para una nueva aplicación Windows Presentation Foundation (WPF) dentro de la misma solución, pero puede elegir cualquier tipo de proyecto pensado para funcionar en forma interactiva con un usuario. Después de crear el proyecto, agrego un controlador de eventos de botón y clics para desencadenar la lógica de invocación de Web API.
ADAL se distribuye en forma de paquete NuGet. Para agregarlo al proyecto cliente, simplemente abra la Consola del administrador de paquetes desde el menú de Herramientas en Visual Studio y escriba Install-Package Microsoft.IdentityModel.Clients.ActiveDirectory -Version 1.0.0. Ahora agregue el código de la figura 7 al controlador de eventos de clics.
Figura 7 Código para agregar el controlador de eventos de clics
private async void btnCall_Click(object sender, RoutedEventArgs e)
{
// Get token
AuthenticationContext ac = new AuthenticationContext(
"https://login.windows.net/cloudidentity.net");
AuthenticationResult ar =
ac.AcquireToken("https://cloudidentity.net/WindowsAzureADWebAPITest",
"a4836f83-0f69-48ed-aa2b-88d0aed69652",
new Uri("https://cloudidentity.net/myWebAPItestclient"));
// Call Web API
string authHeader = ar.CreateAuthorizationHeader();
HttpClient client = new HttpClient();
HttpRequestMessage request = new HttpRequestMessage(
HttpMethod.Get, "https://localhost:44353/api/Values");
request.Headers.TryAddWithoutValidation("Authorization", authHeader);
HttpResponseMessage response = await client.SendAsync(request);
string responseString = await response.Content.ReadAsStringAsync();
MessageBox.Show(responseString);
}
No se preocupe si el código parece intimidante. Todo se aclarará dentro de unos instantes.
La primera línea inicializa un nuevo AuthenticationContext. En el código de la aplicación, una instancia de AuthenticationContext representa la autoridad con la que trabajamos. En este caso, la autoridad es mi inquilino Windows Azure AD representado por la dirección URI https://login.windows.net/\[midominio\]. Usaríamos la misma lógica para conectarnos a un directorio local al pasar la dirección de su servidor Active Directory Federation Services (AD FS) (consulte bit.ly/1d553F0 si necesita encontrar más información).
La segunda línea le pide un token a AuthenticationContext. Existen muchas formas para confeccionar una solicitud de token: cada caso y cada tipo de aplicación requiere de parámetros diferentes. Aquí, quiero especificar que el recurso para el que necesito un token es mi Web API. Así que lo que paso es el identificador de su entrada en Windows Azure AD. Esto es el mismo valor que se usó en Audience en el proyecto Web API. Luego, como es el cliente nativo el que solicita el token, debo pasar el identificador del cliente y redirigir la URI de mi cliente a la página de configuración de la aplicación que dejé abierta en el explorador.
Esto es todo lo que tenemos que hacer para obtener un token. El código restante coloca ese token en el encabezado HTTP correcto en conformidad con la especificación OAuth 2.0 y realiza la llamada propiamente tal.
Ahora ponga la solución a prueba. Después de cambiar la solución para iniciar todos los proyectos de una sola vez, presione F5. En cuanto la ejecución llega a la llamada a AcquireToken, aparecerá el cuadro de diálogo de autenticación que se muestra en la figura 8. ADAL se encarga de ponerse en contacto con el extremo correcto y de presentar la experiencia de autenticación proporcionada por el servidor en un cuadro de diálogo emergente sin que nosotros tengamos que escribir ni una sola línea de código para la interfaz de usuario.
.png)
Figura 8 Cuadro de diálogo de la biblioteca de autenticación de Active Directory
Cuando proporciono las credenciales de cualquier usuario válido de mi inquilino de directorio, recibo de vuelta un token. El código subsiguiente presenta el token a Web API en los encabezados de las solicitudes. El middleware de seguridad lo valida. Como todos los parámetros de validación coinciden, envía de vuelta un código de estado HTTP 200 con los resultados, lo que concluye correctamente la prueba de concepto para este caso.
Solo por diversión, vuelva a hacer clic en el botón. Verá que esta vez inmediatamente recibe un token de vuelta, sin necesidad de proporcionar ningún tipo de información. Esto se debe a que ADAL cuenta con un almacenamiento caché que registra los tokens. Incluso se encarga de actualizar en silencio los tokens expirados siempre que sea posible.
Pasos siguientes
Apenas vimos someramente algunas de las posibilidades de Web API, los componentes de Microsoft OWIN, Windows Azure AD y ADAL. Los tokens emitidos por Windows Azure AD no son solamente una prueba de autenticación. Contienen información valiosa sobre el usuario a la que podemos tener acceso fácilmente desde la entidad de seguridad del usuario para llevar a cabo una lógica de autorización sofisticada. El proceso de autenticación puede ir mucho más allá del nombre de usuario y contraseña que vimos aquí.
Desde factores de autenticación múltiples hasta el inicio de sesión único en situaciones federadas, las posibilidades no tienen límite. La integración con Graph API puede brindarle acceso a un verdadero tesoro de funcionalidades. Puede consultar el directorio para obtener información que va más allá del usuario actualmente autenticado, desde un selector de personas hasta el rastreo avanzado de estructuras organizacionales.
Estas características se pueden sumar a la funcionalidad de las Web API basadas en la web. Hasta ahora, había que ejecutarlas en forma local detrás del firewall corporativo. También podemos usar código similar con Windows Server Active Directory, en uno de los ejemplos más claros de la simetría que existe en las funcionalidades entre la nube y local.
Por supuesto, también podemos publicar Web API en Windows Azure sin cambiar ni una sola línea de código; las funciones de autenticación seguirán funcionando. Lo único que tenemos que cambiar está en el proyecto cliente. La dirección URL del servicio cambiará de acuerdo con la nueva ubicación de la aplicación. Sin embargo, la lógica para adquirir un token puede seguir siendo exactamente la misma, ya que no hace falta que el identificador del recurso esté enlazado con la dirección física del recurso.
Vittorio Bertocci es jefe de programa principal en el equipo de Windows Azure AD, donde está a cargo de la experiencia para desarrolladores. Bertocci es reconocido en la comunidad por sus actividades de evangelización durante toda una década sobre identidad y desarrollo a través de sus libros, sus sesiones en los principales congresos, su blog (cloudidentity.com) y su fuente de Twitter (twitter.com/vibronet).
Gracias a los siguientes expertos técnicos de Microsoft por su ayuda en la revisión de este artículo: Howard Dierking y Daniel Roth
Howard Dierking es jefe de programas en el equipo de marcos y herramientas para Windows Azure, donde se concentra en ASP.NET, NuGet y Web API. Previamente, Dierking actuó como redactor jefe de MSDN Magazine y también estaba a cargo del programa de certificación de desarrolladores de Microsoft Learning. Antes de entrar a Microsoft, trabajó durante diez años como desarrollador y arquitecto de aplicaciones con un enfoque en sistemas distribuidos.
Daniel Roth es director jefe de programas en el equipo de la plataforma de aplicaciones para Windows Azure y actualmente trabaja en ASP.NET Web API. Antes de esto trabajó en WCF, desde la primera versión de .NET Framework 3.0. Una de sus pasiones es deleitar a los clientes con marcos sencillos que sean fáciles de usar.