Si no terminas de entender muy bien la diferencia entre estas siglas o quieres conocer un poco más estas tecnologías y modelos Business to Business y Business to Consumer te invitamos a que sigas leyendo esta nueva entrada; en ella vamos a hablar de las identidades externas en Azure AD y de cómo podemos, de una forma sencilla, integrarlas en nuestros entornos para que puedan interactuar con nuestros recursos.
B2B
Empezaremos por orden cronológico según la primera que llegó al mercado, Azure AD B2B.
Azure AD B2B es el escenario más común de todos y al que más acostumbrados estamos. Nos permite invitar a nuestros socios de negocio y colaboradores a nuestro directorio de forma que puedan hacer uso de nuestros recursos y aplicaciones, pero siempre usando su propia identidad, sin la necesidad de crearles usuarios específicos y por supuesto sin tener que gestionar el ciclo de vida de dichas cuentas y contraseñas.
El escenario típico en una relación B2B es la colaboración por parte de partners con aplicaciones alojadas en nuestro directorio. Por ejemplo, cualquier aplicación de Office 365. Cuando invitamos a un usuario externo para que pueda editar un documento compartido alojado en una biblioteca de Sharepoint Online estamos, de forma intrínseca, creando una relación B2B entre ambos tenants.
Cuando los usuarios B2B invitados acceden a los recursos a los que se le ha otorgado acceso se crea un objeto usuario en nuestro directorio similar a un usuario propio interno del mismo (aunque con otra nomenclatura). Esta cuenta de usuario se puede gestionar como si de un usuario interno se tratase, pudiendo incluirla en grupos de usuario, asignarle permisos de acceso a recursos, etc.
Aunque se cree este objeto de usuario en nuestro directorio es importante destacar que es el directorio original del usuario (en caso de identidad Microsoft profesional) o los servicios de Microsoft (en caso de identidad Microsoft personal o cualquier cuenta de correo) el responsable de autenticar al usuario, validando las credenciales presentadas y devolviendo a nuestro directorio, donde reside la aplicación destino, el token ya validado. El ciclo de vida de dicho usuario es responsabilidad de su directorio origen y nosotros desde nuestro directorio no tenemos que preocuparnos de aspectos como el reseteo de la contraseña o la política de expiración de la misma. Lo único que debemos gestionar es el extremo de la aplicación o recurso accedido en sí, controlando aspectos como qué usuarios o grupos tienen acceso y con qué nivel de permisos, si se les requiere MFA o si cuentan con SSO en el acceso o no.
B2C
Ok pero, ¿Qué ocurre cuando el escenario en el que queremos movernos está más orientado a clientes finales? Ya no se trata de una relación entre partners para acceder a unos recursos compartidos o una aplicación interna, sino que nuestro modelo de negocio se basa en los clientes finales a quienes queremos proporcionar acceso a, por ejemplo, una aplicación a medida que hemos desarrollado e integrado en nuestro directorio. Para dar solución a este escenario surgió Azure AD B2C.
La ventaja principal de Azure AD B2C es el poder crear un directorio de identidades en la nube para los clientes.
Este escenario es bastante distinto al anterior. Hablamos de un servicio diferente a Azure AD y separado de él. En este caso las cuentas de usuario cliente se crean en un directorio aparte, separado del directorio principal donde tenemos a los usuarios internos o a los de B2B.
En Azure AD B2C proporcionamos a los propios clientes la capacidad de poder registrarse ellos mismos en dicho directorio de identidades y de esta forma poder acceder a los servicios publicados sin necesidad de tener que darlos de alta. Además, no tienen por qué usar cuentas Microsoft corporativas o personales si no que pueden iniciar sesión directamente con sus credenciales de otros proveedores sociales como Facebook, Google, LinkedIn, Amazon o Twitter. En todos estos casos en los que los usuarios utilizan su identidad social, la validación de las credenciales recae en los propios proveedores de identidades y no en Azure AD B2C, por lo que tampoco en este caso debemos preocuparnos de la gestión de las contraseñas.
Algunos conceptos clave de Azure AD B2C:
- Tenant: Como hemos comentado, el tenant donde se almacenan los datos de los usuarios es un tenant y directorio separados por completo de nuestro directorio principal. En él además se registran las aplicaciones que vayan a ofrecer la posibilidad de utilizar las funciones B2C.
- Flujos de usuario: Para poder definir la forma en la que los usuarios interactúan con el directorio se utilizan los flujos de usuario. Estos flujos constan de varios pasos y definiciones mediante los cuales se configuran los métodos para hacer login, registrar un nuevo usuario (en el caso de cuentas locales), resetear una password (en el caso de cuentas locales) o editar el perfil de un usuario. Existen flujos de usuario ya predefinidos con las tareas más comunes, aunque el verdadero potencial está en el uso de las custom policies mediante las cuales podemos personalizar por completo estos procesos más complejos para poder adaptarlos a las necesidades del negocio. Personalizando estas custom policies podemos por ejemplo incluir verificación adicional mediante teléfono móvil, requerir que el usuario rellene ciertos datos en el primer inicio, requerir MFA o utilizar acceso OTP y password-less. La personalización de estas custom policies se realiza modificando el código incluido en varios archivos XML de configuración y requiere un conocimiento y experiencia amplios si se persiguen escenarios de autenticación complejos.
- Tipos de cuentas de usuario en B2C:
- Cuenta profesional: Son cuentas utilizadas exclusivamente para administrar el tenant.
- Cuenta de invitado: Usuarios de otros tenants a los que es posible invitar para colaborar en labores de administración. Es como crear una relación B2B dentro del tenant B2C.
- Cuenta de consumidor: Son las cuentas de usuario final propiamente dichas. Estas cuentas se crean en el directorio B2C cuando el usuario completa el primer inicio de sesión en una aplicación registrada en el directorio o ejecuta el proceso de registro en las mismas. Éstas a su vez pueden ser de 3 tipos diferentes en función del origen del que procedan:
- Cuenta local: Creada en el directorio B2C como parte del proceso de registro en B2C llevado a cabo por un usuario. Se almacena en este caso la password del mismo puesto que esta credencial sí que se valida contra el directorio B2C. Este tipo de cuenta se crea cuando el usuario quiere registrarse para utilizar una aplicación, pero no quiere hacerlo con ninguna identidad que ya posea de otros proveedores, sino que quiere crear un usuario expresamente para usar la aplicación.
- Identidad social: Cuando el usuario es administrado mediante un proveedor de identidad (IdP) externo como Microsoft (cuentas profesionales o personales), Facebook, LinkedIn, etc. En este caso el usuario utiliza una credencial que ya posee y no es necesario crear un nuevo usuario solo para utilizar la aplicación de nuestro directorio, facilitando así la experiencia de los usuarios finales. La password de los usuarios no se almacena en B2C puesto que no es responsable de la validación de las credenciales de los mismos. Dentro del directorio B2C podemos configurar esta federación con los proveedores de identidades externos que deseemos, de manera que éstas se muestren como opciones de inicio de sesión a los usuarios cuando intenten acceder a nuestras aplicaciones.
B2X o External Identities
Este concepto empezó a oírse hace relativamente poco tiempo. En realidad, no existe dentro de Azure nada con este nombre, aunque se ha utilizado de un tiempo a esta parte para intentar etiquetar con siglas la tendencia que está siguiendo Microsoft poco a poco de ir uniendo los dos mundos B2B y B2C en uno solo, dando lugar a ese nuevo modelo B2X que tantas expectativas está generando.
Podemos decir que desde mayo de este año 2020, en que fue presentado en el MSBuild20, existe este concepto en Azure, aunque Microsoft ha optado por darle un nombre menos impactante y que lo define de manera más sencilla: Azure AD External Identities.
¿Qué es Azure AD External Identities?
Un nuevo escenario mediante el cual podemos dar acceso a nuestros socios de negocio, proveedores o usuarios consumidores a nuestros recursos y aplicaciones permitiendo traer y utilizar sus propias identidades, ya sean propias de otros tenant Azure AD o identidades sociales como Facebook o Google. Los usuarios utilizan su propia identidad existente en los proveedores de identidad mencionados para acceder y son esos proveedores de identidades los que la gestionan, permitiendo que nosotros solo nos preocupemos del otro extremo de la relación, es decir, del acceso a las aplicaciones.
Es la unión de ambos conceptos B2B y B2C en una sola experiencia y un punto único de gestión.
¿Qué novedades aporta Azure AD External Identities?
- Todos los tipos de usuario ya sean socios de negocio y proveedores (B2B) o usuarios consumidores (B2C) están agrupados en el mismo directorio Azure AD y, además, es el directorio Azure AD principal (Como ya ocurría con las cuentas B2B, que de por sí no se gestionaban en un directorio aparte)
- Flujos de usuario predefinidos para el registro de usuarios de autoservicio en nuestras aplicaciones. No solo para usuarios B2C sino también para los socios B2B. En el pasado, con B2B tradicional, era necesario invitar a nuestros socios para que pudiesen, aceptando esa invitación enviada por correo, acceder a nuestros recursos. Con External Identities los flujos de usuario, funcionalidad propia de entornos B2C, han sido incorporados para ofrecer estas experiencias de registro de autoservicio a todos los tipos de usuario.
*Nota: Actualmente External Identities no admite el registro de autoservicio con usuarios locales creados al momento (como ocurría en B2C) si no que es necesario registrarse con una identidad existente (Otro Azure AD, Google, Facebook, SAML IdP)
- Atributos de usuario personalizados que nos permiten, durante ese proceso de registro en las aplicaciones usando los flujos de usuario, recoger información adicional de los usuarios que pueda ser relevante para la aplicación que van a utilizar.
- Mecanismos de federación directa y simple con proveedores de identidades sociales como Google y Facebook. Estas integraciones y el uso de este tipo de identidades en flujos de usuario para registro de autoservicio o autenticación ha sido algo que, tradicionalmente en entornos B2C, ha implicado tiempo y esfuerzo modificando archivos xml de custom policies para lograrlo. El proceso de integración y uso de estos proveedores de identidades en External Identities mediante flujos de usuario se ha simplificado al extremo.
- Conectores API para llamadas a APIs web durante los flujos de autenticación de usuarios para, por ejemplo, hacer uso de nuestro propio sistema de aprobación personalizado.
Veamos Azure AD External Identities funcionando para entender mejor las diferencias con los procesos que ya existían en B2B y B2C.
En los siguientes ejemplos se muestran características que aún están en fase preview por lo que lo mejor es implementar estos cambios desde el portal https://preview.portal.azure.com/
A continuación, mostramos el proceso a seguir para poner a prueba las nuevas funcionalidades de Azure AD External Identities mencionadas en párrafos anteriores. No daremos todo el detalle para no alargar en exceso la entrada en el blog:
- Habilitar los flujos de autoservicio de usuarios
Sin esta característica no es posible ejecutar ninguno de los pasos posteriores.
- Realizar la integración de Google y Facebook como proveedores de identidades
Para poder utilizar identidades de estos proveedores es necesario seguir un proceso sencillo de configuración en los portales para desarrolladores de cada uno de ellos, crear una aplicación y registrarla para, posteriormente incluir dicha información en nuestro tenant. De esta forma integramos ambos proveedores de identidades en nuestro directorio.
Al activar esta opción se registra en el directorio una extensión llamada aad-extension-app que es la encargada de recoger la información de usuarios externos e incorporarla a nuestro directorio.
- Crear nuevos atributos en el directorio
Para esta prueba creamos 2 atributos nuevos de ejemplo. Uno de ellos albergará el nombre de la empresa a la que pertenece el usuario y el otro, un campo de tipo booleano, donde indicará si es mayor de edad o no. Ambos serán recogidos durante el registro de autoservicio de usuarios.
- Crear un flujo de autoservicio que permita a los usuarios registrarse usando una cuenta Microsoft corporativa de otro directorio, una identidad de Google o una identidad de Facebook.
Para ello creamos un nuevo flujo de usuario al cual le asignamos los 3 tipos de identidades que vamos a permitir para esta aplicación tanto para el inicio de sesión como para el registro de autoservicio en la misma.
En el apartado de atributos podemos marcar el orden en el que le aparecerán al usuario para rellenarlos, los que son obligatorios u opcionales e incluso los valores a mostrar en los cuadros de selección según el tipo.
- Asociación de una aplicación previamente registrada en el directorio con este flujo de usuario.
Es necesario asociar este nuevo flujo a una aplicación del directorio para que, cuando los usuarios la utilicen, tengan la posibilidad de iniciar sesión o registrarse en la misma con las opciones que hemos configurado.
De esta forma además podemos tener diferentes flujos de usuario para cada una de las aplicaciones para las cuales queremos añadir esta capacidad de autoservicio.
Para esta demo utilizamos una app que simplemente nos permite logarnos en el directorio y posteriormente nos muestra información de nuestro perfil.
- Registro de autoservicio en una aplicación previamente registrada en el directorio haciendo uso de estos 3 tipos distintos de credenciales.
Una vez tenemos todo el entorno preparado nuestra aplicación ya está lista para utilizar este nuevo flujo de usuario.
Un usuario que acceda a la aplicación encontrará un formulario donde se le ofrece la posibilidad de registrarse como nuevo usuario en la misma (dado que suponemos que nunca ha accedido a ningún recurso ni aplicación de nuestro directorio).
Tras elegir qué tipo de identidad va a utilizar (Cuenta Microsoft, Google o Facebook), dado que hablamos del primer acceso del usuario o registro de autoservicio, se le muestra el cuadro de recogida de información para darle de alta en el directorio. En él aparecen los atributos que previamente habíamos seleccionado y configurado en el flujo de usuario.
Tras el registro por parte del usuario se muestra la aplicación y el usuario puede hacer uso de ella como cualquier otro usuario existente.
Como decíamos al principio del apartado, una de las diferencias de B2X (External Identities) es que todos los usuarios comparten directorio, ya sean identidades corporativas (comúnmente conocidas como B2B) o identidades sociales (B2C), sin necesidad de gestionar directorios paralelos para usuarios consumidores. Aquí podemos ver cómo las 3 identidades utilizadas están registradas en el directorio principal donde también está registrada la aplicación que utilizan.
Aparecen, en la columna Tipo de Creación, el nombre SelfServiceSignUp indicando que ha sido el propio usuario el que se ha registrado mediante el proceso de autoservicio. Este campo es útil para filtrar posteriormente y extraer estadísticas e informes.
Dentro de los detalles de los usuarios vemos incluso el proveedor de identidades utilizado.
Conclusión
Azure AD External Identities (o B2X en su acepción menos conservadora) es actualmente la respuesta a quienes tengan la necesidad de incorporar mecanismos de autoservicio a sus aplicaciones o quieran facilitar el acceso de usuarios consumidores con identidades sociales a sus aplicaciones sin grandes requerimientos ni complejidad. Con no demasiado esfuerzo se puede conseguir un funcionamiento básico que cubra estos escenarios iniciales.
Para quienes requieran de procesos de login o registro más elaborados, incluyendo otros proveedores de identidades, con verificación de identidad con más de un mecanismo o pretendan poner a disposición de los usuarios posibles flujos más complejos, como reseteo de contraseñas, o incluso quieran ofrecer la posibilidad de registro de autoservicio para crear usuarios locales en el directorio, Azure AD B2C sigue siendo la única opción a día de hoy. Azure AD B2C es un producto con mucho recorrido y gran capacidad de configuración y personalización que, con el correspondiente esfuerzo según la necesidad, cubre los escenarios más complejos.
Azure AD External Identities es claramente el futuro de la colaboración con entidades externas en Azure AD.
Microsoft está incorporando poco a poco a este nuevo escenario B2X común funcionalidades de B2B y B2C que sin duda los administradores de Azure llevábamos tiempo necesitando, pero aún queda recorrido. No hay que olvidar que la mayoría de las funcionalidades relacionadas con Azure AD External Identities están todavía en fase preview.
Nos mantendremos a la espera de novedades en los próximos meses que seguro llegarán para seguir haciendo crecer este nuevo marco común B2X.
Imagen portada: Fuente Microsoft
Este obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial 4.0 Internacional.
