Empezaré diciendo que las tecnologías de identidad actuales pueden resultar muy confusas. Existen numerosos servicios (en la era de la nube, todo es un servicio), protocolos, soluciones, SDK, tecnologías y productos destinados a resolver el problema de la identidad.

Empezaré comparando los dos conceptos básicos que pueden resultar más confusos, ya que comparten el mismo nombre: los clásicos Servicios de dominio de Active Directory (ADDS, por sus siglas en inglés) y Windows Azure Active Directory (AAD, por sus siglas en inglés).

ADDS se lleva utilizando desde hace una eternidad (bueno, 13 años en informática parecen una eternidad) para proporcionar servicios de autenticación y autorización (AuthN y AuthZ) dentro del centro de datos empresarial (el entorno local). Es bastante popular (el 87 % de las empresas de la lista Fortune 1000 lo utilizan, según Gartner) y ha demostrado ser bastante sólido a la hora de proporcionar todos los servicios necesarios. (Aclaración: solía dar soporte técnico para este producto cuando trabajaba en MSFT, así que me gusta bastante).

Pero, en el panorama actual, en constante cambio, eso ya no es suficiente, y el motivo es: ¡la nube!

Cuando nos fijamos en el Centro de Datos local y el entorno de la Nube hay muchas diferencias en los protocolos y soluciones que se están utilizando debido a varias razones, pero las 3 principales son: Seguridad, Privacidad e Interoperabilidad.

Si nos fijamos en los protocolos utilizados en el centro de datos local para la autenticación y autorización, podemos decir con seguridad que Kerberos es el protocolo más común hoy en día, y si nos fijamos en el acceso a los datos utilizado en los centros de datos para acceder al almacén de identidades, diría que LDAP es el protocolo más común soportado por casi todos los proveedores de directorios.

Esto es exactamente lo que hace ADDS Autentica a los usuarios y autoriza el acceso a los recursos mediante Kerberos, y proporciona acceso al almacén de datos mediante el protocolo LDAP.

«Pero luego llegó la nube» (y Facebook, que tiene una conexión muy tangible)

Si nos fijamos en cómo se gestionan (o no se gestionan) la autenticación (AuthN) y la autorización (AuthZ) en la nube, resulta bastante comprensible que Kerberos no sea del todo adecuado.

La razón es que, al utilizar Kerberos, se especifican claves que se emplean para cifrar los tickets de Kerberos y que son proporcionadas por una única fuente autorizada. Eso no es posible en un entorno en la nube (¿qué claves se utilizarían si se quisiera autenticar una cuenta de Facebook en un servicio de Google? ¡No existe un almacén central de identidades ni un proveedor central de claves!).

Así que llegaron SAML, OAuth, OpenID y otros al rescate. Todas ellas son tecnologías que permiten el inicio de sesión federado. (Básicamente, cómo puedo iniciar sesión desde Facebook a Google sin tener que introducir mis credenciales dos veces). Cada una tiene su propia especificación, pero el objetivo principal es permitir la autenticación a través de diferentes servicios de diferentes proveedores de servicios/nube (¿he mencionado la interoperabilidad?).

Si nos fijamos en la capa de acceso a los datos, ocurre lo mismo. Aunque LDAP podría funcionar, hay algo que tiene más sentido a la hora de gestionar las conexiones entre personas (ya sean usuarios de la organización o consumidores con fotos de perfil y muros), ¡y es el Graph!

Utilizar Graph como almacén de datos (especialmente como almacén de identidades) tiene mucho sentido, ya que no es jerárquico como LDAP y, de hecho, puede mostrar las «conexiones» entre los usuarios y los recursos de la organización, lo que permite gestionar realmente una identidad, en lugar de toda una jerarquía utilizada para organizar las identidades en «carpetas» según lo que la organización haya decidido que tiene sentido para ella.

Aquí es donde entra en juego Azure Active Directory. AAD es un IDaaS (Identity as a Service) basado en la nube proporcionado por Microsoft que utiliza estándares abiertos (SAML, por ejemplo) para autenticar usuarios y permitir la federación de identidades entre servicios en la nube, así como el modelo de datos Graph para consultar y gestionar objetos.

Aquí tienes una breve tabla comparativa de ambos:

Azure Active Directory Servicios de dominio de Active Directory
Proporciona SSO y repositorio de usuarios para servicios en la nube. Proporciona SSO y gestión de identidades para servicios locales.
Proporcionar una plataforma extensible para la gestión de funcionesde terceros No permite la gestión de roles en servicios en la nube deterceros.
Proporciona una plataforma de identidad en nube multiusuario Se basa en una plataforma local de un único inquilino
Uso de las normas del sector para la autenticación en la nube Uso de las normas del sector para la autenticación in situ
Utiliza Graph API para acceder a los datos Utiliza el protocolo LDAP para el acceso a los datos

En conclusión ADDS nos proporciona la capacidad de iniciar sesión en nuestra red corporativa, acceder a los recursos ubicados en la red corporativa y permite a los servicios consultar información sobre objetos como usuarios, grupos y recursos.

AAD permite iniciar sesión en nuestros servicios en la nube, acceder a recursos ubicados en la nube y permite a los servicios en la nube consultar información sobre objetos.

Espero que haya servido para entender las dos cosas.

En la próxima entrada intentaré explicar cómo se pueden interconectar ambos para crear una identidad «híbrida» (que permita utilizar la misma cuenta tanto para los recursos locales como para los servicios en la nube).