Definir cómo un usuario inicia sesión, se registra o restablece su contraseña a través de archivos XML es el corazón de las políticas personalizadas en Azure Active Directory B2C. Esta capacidad permite orquestar la confianza entre distintas entidades de identidad —cuentas locales, cuentas sociales o proveedores que usen protocolos como OpenID Connect, OAuth y SAML— con un nivel de control que los flujos predeterminados no ofrecen.
¿Qué son las directivas personalizadas y cómo se estructuran?
Las directivas personalizadas son archivos XML que describen paso a paso lo que debe ocurrir cuando un usuario interactúa con el sistema de identidad [0:12]. Estos archivos se editan preferentemente en Visual Studio Code con un plugin especializado y luego se suben al portal de Azure, dentro de la sección Identity Experience Framework [0:33]. Al momento de subir el archivo, la plataforma realiza una validación de sintaxis; si pasa esa revisión, los errores restantes serán detectados en tiempo de ejecución [1:02].
La estructura jerárquica se compone de tres niveles:
- Trust Framework Base: el archivo fundamental con la configuración raíz [7:48].
- Archivo de extensión: donde se añaden personalizaciones y lógica adicional.
- Archivo de confianza (relying party): la política específica que se ejecuta, como inicio de sesión, registro, edición de perfil o restablecimiento de contraseña.
Cada archivo de confianza hace referencia hacia arriba en la jerarquía, heredando configuraciones de la base y las extensiones. La recomendación es evitar modificar la directiva base y concentrar los cambios en los archivos de extensión y en los archivos de confianza [8:32].
¿Qué ofrece el paquete de inicio rápido?
El quick start o paquete de inicio rápido facilita la configuración inicial del directorio activo y proporciona escenarios simples listos para usar [2:24]. Incluye plantillas para trabajar con:
- Cuentas locales exclusivamente.
- Cuentas sociales como Facebook.
- Combinación de cuentas locales y sociales.
- Cuentas locales y sociales con autenticación multifactor (MFA) [3:04].
Dentro de este paquete ya vienen definidos los claims que Azure Active Directory maneja, incluyendo su tipo, nombre y el protocolo en el que están soportados [3:28].
¿Cómo funcionan los claims y las validaciones con regex?
Un claim es una pieza de información sobre el usuario —como correo electrónico, contraseña o un identificador fiscal—. Al definir un claim, se puede especificar un regex (expresión regular), que es un patrón de texto que la información debe cumplir para considerarse válida [3:48]. Por ejemplo, para la contraseña se puede exigir cierta complejidad, y para el correo electrónico se puede verificar que contenga el formato usuario@dominio antes de enviar un código de verificación [4:12].
¿Cómo funciona el user journey y la orquestación de pasos?
Cuando un usuario hace clic en iniciar sesión, la aplicación indica a Azure AD B2C cuál política ejecutar. Esa política contiene un user journey o recorrido del usuario, compuesto por pasos de orquestación con condiciones específicas [4:48].
El flujo típico incluye:
- Presentar la página de inicio de sesión y capturar credenciales.
- Validar si el usuario se autentica con un proveedor social o con cuenta local.
- Realizar llamadas a una API REST para obtener información adicional.
- Generar el token y enviarlo a la URI de respuesta configurada en la aplicación [5:28].
Durante todo el proceso, la información se acumula en el claims bag (bolsa de claims), un almacén temporal donde cada paso puede leer datos del paso anterior o agregar nuevos [6:28]. Por ejemplo, tras autenticar al usuario, se puede consultar una API para verificar el tipo de licencia activa y su vigencia, incorporando esa información al token final.
¿Qué es un perfil técnico de validación?
El perfil técnico de validación permite detectar errores en la información proporcionada por el usuario y ejecutar verificaciones adicionales [7:04]. Funciona en dos momentos clave: primero valida que las credenciales sean correctas y luego puede llamar a servicios externos para confirmar, por ejemplo, si el usuario tiene permisos para continuar o si los datos ingresados son coherentes antes de crear una cuenta.
¿Qué considerar para alta disponibilidad y rendimiento?
Azure AD B2C está diseñado para manejar millones de autenticaciones diarias. Sin embargo, si durante el proceso de autenticación se invoca una API externa, esa API debe estar configurada en alta disponibilidad para soportar el volumen de peticiones [9:08]. De igual forma, los recursos de personalización de interfaz —imágenes, hojas de estilos, JavaScript— deben alojarse en una content delivery network (CDN) para mejorar tiempos de respuesta y evitar sobrecargar el servidor de origen [9:30].
Con esta base clara sobre la estructura y el comportamiento de las políticas personalizadas, el siguiente paso es explorar ejemplos concretos y construir desde cero con el paquete de inicio rápido. ¿Ya tienes identificado qué escenario de identidad necesita tu aplicación? Comparte tu caso en los comentarios.
