Empezaré diciendo que las tecnologías de identidad actuales pueden ser muy confusas. Hay muchos servicios (en la era de la nube todo es un servicio), protocolos, soluciones, SDK, tecnologías y productos que pretenden resolver el problema de la identidad.
Empezaré comparando los dos básicos, que pueden ser los más confusos, ya que comparten el mismo nombre: el viejo Active Directory Domain Services (ADDS) y Windows Azure Active Directory (AAD).
ADDS se utiliza desde hace años (bueno, 13 años en ordenadores parecen siglos) para proporcionar servicios de autenticación y autorización (AuthN y AuthZ) dentro del centro de datos de la empresa (el entorno local). Es bastante popular (el 87% de Fortune 1000 lo utiliza, según Gartner) y ha sido bastante sólido a la hora de proporcionar todos los servicios necesarios. (Descargo de responsabilidad: yo trabajaba para MSFT, así que me gusta el producto).
Pero en el cambiante panorama actual ya no es suficiente, y la razón es: ¡Ze Cloud!
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 entonces llegó la nube' (Y Facebook, que tiene una conexión muy tangible)
Viendo cómo se gestionan (o no se gestionan) AuthN y AuthZ en la nube es bastante comprensible que Kerberos no sea lo suficientemente bueno.
La razón es que cuando se utiliza Kerberos se especifican claves que se utilizan para cifrar los tickets Kerberos y que son proporcionadas por una única fuente autorizada. Eso no es posible en el entorno de la nube (¿qué claves utilizarías si quisieras autenticar una cuenta de Facebook en un servicio de Google? No hay 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?).
En cuanto a 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 la conexión entre personas (ya sean usuarios organizativos, o consumidores con fotos de perfil y muros), ¡que es el Graph!
Utilizar Graph para almacenar datos (especialmente un almacén de identidades) tiene mucho sentido, ya que no es jerárquico como LDAP, y puede mostrar realmente "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" en función de lo que la organización haya decidido que tiene sentido para ellos.
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.
He aquí 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 ofrece la posibilidad de gestionar las funciones de los servicios en la nubede terceros. |
| 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 las dos para obtener una identidad "híbrida" (que permita utilizar la misma cuenta tanto para los recursos locales como para los servicios en la nube).
