Al igual que en un entorno on-Premise la nube necesita de un mecanismo de control de acceso a los diferentes recursos disponibles. En un entorno de trabajo global todos los empleados de una organización necesitan acceso a algunos servicios de Azure para realizar sus tareas. Imaginemos un recurso de almacenamiento compartido, una máquina virtual o una base de datos SQL, todos tienen en común la necesidad de que cada usuario pueda identificarse y acceder de acuerdo al rango de privilegios otorgado por el administrador. Aquí es donde entra en escena Azure Active Directory (AD).
Azure Active Directory (también conocido como Azure Active Directory) es un servicio multi inquilino completamente administrado de Microsoft que ofrece capacidades de identidad y acceso para aplicaciones que se ejecutan en Microsoft Azure y para aplicaciones que se ejecutan en un entorno local. Esto hace que a menudo pueda ser confundido con Active Directory para Windows Server, pero en realidad esto va mucho más allá de lo que ya estamos familiarizados en entornos Windows. Para resumirlo, no, Azure Active Directory no es Active Directory ejecutándose en máquinas virtuales de Azure.
Otro error es suponer que Azure Active Directory sustituye a Windows Server Active Directory. En realidad puede complementarlo extendiendo a la nube las capacidades de nuestro directorio local. En estos escenarios, los usuarios y grupos del directorio local se sincronizan con Azure Active Directory mediante una herramienta como Azure Active Directory Sync (AAD Sync).
Esto tiene la ventaja de que los usuarios pueden autenticarse contra Windows Server Active Directory cuando acceden a aplicaciones y recursos locales, y autenticarse contra Azure Active Directory cuando acceden a aplicaciones en la nube. Así el usuario puede autenticarse con las mismas credenciales en ambos escenarios.
Azure Active Directory también puede ser el único servicio de directorio de una organización. Por ejemplo, hoy en día comienza a ser muy normal que las empresas emergentes no cuenten con una complicada infraestructura de servidores buscando ahorrar costes o que sus empleados se encuentren completamente deslocalizados alrededor del planeta trabajando remotamente. En estos escenarios, una organización puede simplemente confiar en Office 365 y otras aplicaciones SaaS para dotar a sus empleados de las herramientas de trabajo necesarias y administrar la identidad de su usuario y el acceso en línea.
Pero es que además, si eres desarrollador de aplicaciones en la nube, con Azure Active Directory podemos lograr cosas como el inicio de sesión único (SSO) para nuestras aplicaciones, consultar los permisos e información de usuarios y grupos, e incluso escribir cambios en el directorio.
Por supuesto que si lo pensamos, vendrán a la mente otras tecnologías que nos permitirán hacer lo propio, como Kerberos, LDAP, etc. Sin embargo, a medida que nuestros desarrollos se centran cada vez más en la nube, siendo requisito que el acceso se produzca desde un número tan creciente como variado de dispositivos, cruzando los límites organizacionales, esto se traduce en un nuevo paradigma a resolver en el manejo de las necesidades de autenticación de una organización y las aplicaciones de las que depende.
No son pocas las personas que creen que Azure Active Directory (AAD) es solo la versión cloud de Windows Active directory (AD) pero en realidad se trata de una evolución que lleva mucho más allá sus capacidades. Active Directory (AD) es un servicio de directorio de SO que facilita el trabajo con recursos de red interconectados, complejos y diferentes de manera unificada. Pero el mayor inconveniente de Windows Active Directory era que tenía muchas capas que realizaban varios trabajos. Estas capas se enumeran a continuación:
ADDS - Windows Active Directory Domain Services
ADLS - Azure Data Lake Storage Services
ADFS - Active Directory Federation Services
ADCS - Active Directory and Certification Services
ADRMS - Active Directory Rights Management Services
Aquí es donde Azure Active Directory cambió todo el juego. Integra todas estas cinco capas en dos, y estas son:
WAAD - Windows Azure Active Directory. Esta capa combina todos los problemas relacionados con la gestión de identidades.
WAACS - Windows Azure Access Control Service. Esta capa habilita la federación o la división de todos estos servicios de una organización. Aquí la división significa asignar cada uno de estos servicios a los usuarios.
Por lo tanto, Azure Active Directory simplifica muchos problemas al usar solo dos capas. Por ejemplo, Office 365 usa Azure Active Directory para administrar las identidades de los usuarios. Para hacer uso de cualquiera de los servicios de Office 365 como Excel, PowerPoint o Microsoft Word, el administrador solo necesitaría proporcionar un único nombre de usuario y contraseña.
En Azure Active Directory hay dos entidades que nos preocupan más durante el desarrollo de aplicaciones; el usuario y quizás el grupo (o grupos) del que forma parte el usuario. Esto es importante para definir el comportamiento de la aplicación, cómo personalizar pantallas o administrar permisos sobre lo que el usuario puede hacer. En Azure podemos hacer uso de un token de autenticación para simplificar el proceso.
En este escenario, los tipos de usuarios que podemos encontrar son las cuenta de trabajo o de estudiante (anteriormente denominada cuenta de organización), o bien, los provenientes de una cuenta de Microsoft.
Los usuarios generalmente se añaden al directorio en Azure como un usuario de cuenta de trabajo o de estudiante (anteriormente conocido como cuentas de organización). El nombre de usuario y la dirección de correo electrónico de un usuario adoptarán la forma de <someuser> @ <someorg> .onmicrosoft.com y la cuenta normalmente existe mientras el usuario sea parte de la organización o hasta que un administrador elimine la cuenta.
Pero también es posible agregar usuarios procedentes de un directorio diferente en Azure Active Directory. Esto es especialmente útil cuando tenemos usuarios externos, procedentes de otra organización, que necesitan acceder a aplicaciones en común protegidas y administradas por Azure Active Directory. La principal ventaja es que esto se produce de una manera mucho más simple y transparente que en entornos basados en Active Directory.
Durante la autenticación, los usuarios de cuentas de trabajo o estudiantes pueden notar el ícono de insignia azul que se muestra una vez accedemos con nuestras credenciales en la parte superior. Este icono es una pista visual para saber si nuestro usuario inicia sesión con una cuenta de trabajo o de estudiante.
También podemos agregar usuarios a un directorio en Azure usando una cuenta de Microsoft. En este escenario, el nombre de usuario y la dirección de correo electrónico probablemente tomarán la forma de <usuario>@hotmail.com, <usuario>@ outlook.com o <usuario>@live.com.
Este tipo de cuentas son útiles cuando un usuario es un mero consumidor de servicios como Xbox LIVE, Messenger, Outlook / Hotmail, etc. A diferencia de la cuenta de organización, estas cuentas no se eliminan cuando se eliminan de un directorio en Azure. Este tipo de cuentas pertenecen a la persona y no a una organización. Pero los administradores pueden agregar este tipo de usuarios en su directorio como usuarios externos del directorio.
Los usuarios y grupos se pueden agregar a un directorio de varias formas. Sin ningún orden en particular, por ejemplo:
Sincronizando desde un Active Directory de Windows Server local mediante AAD Sync.
Manualmente mediante el Portal de administración de Azure.
Mediante PowerShell
Mediante la API Graph de Azure Active Directory.
Hasta ahora hemos hablado un poco sobre Azure Active Directory y los diferentes perfiles de usuario y cuentas. Ahora toca tratar otro tema no menos importante. Cada directorio de Azure Active Directory obtiene un nombre DNS único en el dominio compartido *.onmicrosoft.com. Por ejemplo, para un directorio llamado "ifgeek", el nombre DNS sería ifgeek.onmicrosoft.com. Por tanto, un usuario del directorio tendría un nombre de usuario como pepito.grillo@ifgeek.onmicrosoft.com.
Pero también podemos hacer uso de un nombre de dominio personalizado. Esto es algo opcional, pero bastante demandado por clientes que prefieren usar su propio nombre de dominio. Continuando con el mismo ejemplo, si fuera propietario del dominio ifgeekthen.com, un nombre de usuario tendría el formato john.doe@ifgeekthen.com en lugar de pepito.grillo@ifgeek.onmicrosoft.com.
Hacer este ajuste, configurar nuestro dominio y asociarlo a nuestro directorio en Azure Active Directory, no necesitaremos de una gran inversión de tiempo. Solo debemos verificar el dominio que queramos usar, incluyendo un registro TXT y un valor proporcionado por Azure para demostrar que somos propietarios del dominio y seguir los pasos para configurar un dominio personalizado detallado en este artículo.
Azure Active Directory proporciona compatibilidad con todos los protocolos comunes que se pueden usar para proteger nuestras aplicaciones. Algunos de estos protocolos son de sobra conocidos , otros todavía están surgiendo. Algunos de los protocolos admitidos en el momento de escribir este artículo son los siguientes:
WS-Federation: este es posiblemente uno de los protocolos más conocidos y utilizados en la actualidad para autenticar usuarios de aplicaciones web. Usado por Microsoft para autenticar usuarios en sus propias aplicaciones en la nube, como el portal de administración de Microsoft Azure, Office 365, Dynamics CRM Online y más.
SAML-P: este también es un protocolo ampliamente adoptado y sigue un patrón de autenticación muy similar al de WS-Federation.
OAuth 2.0: Este es un protocolo de autorización que se ha adoptado rápida y ampliamente en la industria.
OpenID Connect: Este es un protocolo que agrega una capa de autenticación sobre el protocolo OAuth 2.0 existente.
Antes de desplegar nuestras aplicaciones para que nuestros usuarios puedan hacer uso de ellas, es necesario agregarlas en un tenant de Azure Active Directory. Al agregar la aplicación o registrarla definimos la configuración que Azure Active Directory necesitará para identificar nuestra aplicación como una aplicación legítima para que pueda emitir tokens de autenticación al autenticar usuarios.
Las aplicaciones que desarrollemos, por tanto, se pueden registrar en un directorio en Azure Active Directory mediante el uso de herramientas específicas como Visual Studio, el Portal de administración de Azure u otras herramientas de línea de comandos. Si bien el el Portal de administración de Azure proporciona una experiencia de asistente sencilla, lo más recomendable para proyectos de cierta envergadura es utilizar Visual Studio o mediante PowerShell y Azure CLI.
Con independencia de esto, durante el proceso de registro, debemos indicar el tipo de aplicación que vamos a agregar. La razón por la que el tipo es importante es porque es aquí donde se recopilarán los artefactos de protocolo necesarios que lo llevarán eventualmente al uso de WS-Federation u OAuth/OpenID Connect. Las dos opciones son:
Aplicación web y/o API web: para aplicaciones o servicios web basados.
Aplicación de cliente nativo: para aplicaciones de cliente que se ejecutarán en entorno multiplataforma (web, móvil, escritorio, etc).
Y llegamos al final del artículo. En éste hemos presentado a Azure Active Directory, su importancia, y algunos de sus conceptos más importantes. El mundo de la computación en la nube se expande cada día que pasa; muchas empresas de todo el mundo están cambiando a la nube aprovechando las ventajas que ofrecen las plataformas en la nube.
En este escenario, Microsoft Azure es uno de los proveedores de servicios en la nube más importantes. Por esa razón es importante no solo conocer sus fundamentos, también el adquirir destrezas que nos ayuden a desenvolvernos con soltura entre sus múltiples posibilidades y los proyectos que allí podemos crear. Desde configurar nuestro cluster de máquinas virtuales a crear complejas aplicaciones web.
En un entorno de trabajo global todos los empleados de una organización necesitan acceso a algunos servicios de Azure para realizar sus tareas. Cada usuario debe poder identificarse y acceder al rango de privilegios que otorga el administrador. Aquí es donde entra en escena Azure Active Directory (AD).
ifgeekthen.nttdata.com es un blog del grupo NTT DATA. Un proyecto que busca compartir con profesionales del mundo digital temas relacionados con la tecnología y el universo geek.
