Ahora que conocemos las capas del modelo, vamos a profundizar en la arquitectura técnica: cómo Azure AD y Dataverse trabajan juntos, el flujo de autenticación, y por qué a veces los cambios de seguridad tardan en aplicarse.
Objetivos de aprendizaje
- Conocer la arquitectura técnica del sistema de seguridad en Dataverse
- Entender el rol de Microsoft Entra ID (Azure AD) en la autenticación
- Comprender el flujo completo de autenticación y autorización
- Conocer las protecciones avanzadas disponibles
Dos sistemas, una experiencia
Cuando abres Dynamics 365 o Power Apps e inicias sesión, estás interactuando con dos sistemas diferentes sin darte cuenta. Microsoft ha hecho un excelente trabajo integrándolos para que la experiencia sea fluida, pero entender qué hace cada uno te ayudará a diagnosticar problemas y configurar correctamente la seguridad.
Microsoft Entra ID: el guardián de la puerta
Microsoft Entra ID (el nuevo nombre de Azure Active Directory, aunque muchos seguimos diciendo "Azure AD") es responsable de la autenticación. Cuando escribes tu usuario y contraseña, es Entra ID quien verifica que esas credenciales son correctas. También es quien gestiona:
- Autenticación multifactor (MFA)
- Políticas de acceso condicional ("desde esta red sí, desde esa no")
- Single Sign-On con otras aplicaciones
- Gestión de identidades externas (partners, clientes)
El resultado de una autenticación exitosa es un token: un paquete de información firmado digitalmente que dice "este usuario es quien dice ser y fue verificado correctamente". Este token viaja con cada solicitud que haces al sistema.
Dataverse: el guardián del tesoro
Una vez que Entra ID confirma tu identidad, entra Dataverse. Cada vez que intentas hacer algo (ver una oportunidad, crear un contacto, eliminar un lead), Dataverse verifica si tienes permiso para esa acción específica.
Esta verificación considera:
- Tus roles de seguridad
- La unidad de negocio donde estás
- Los equipos a los que perteneces
- La propiedad del registro específico
- Si alguien te ha compartido ese registro
- Si hay Field Security aplicado
Mientras Entra ID se pregunta "¿eres tú?", Dataverse se pregunta "¿puedes hacer esto?".
El flujo completo paso a paso
Vamos a seguir el viaje de una solicitud desde que haces clic hasta que ves los datos:
Paso 1: Abres Dynamics 365 en tu navegador. La aplicación ve que no tienes un token válido (o que expiró) y te redirige a Entra ID.
Paso 2: Entra ID te pide credenciales. Introduces usuario y contraseña. Si tienes MFA habilitado, te pide el código. Si hay políticas de acceso condicional, las evalúa (¿estás en un dispositivo compliant? ¿desde una red permitida?).
Paso 3: Si todo está bien, Entra ID genera un token JWT (JSON Web Token) que contiene tu identidad y algunos metadatos. Te redirige de vuelta a Dynamics 365 con ese token.
Paso 4: Dynamics 365 incluye ese token en cada solicitud que hace a Dataverse en tu nombre.
Paso 5: Dataverse recibe la solicitud, valida el token (verifica que no está expirado, que la firma es correcta, que viene de Entra ID), y luego consulta su motor de seguridad para ver si tienes permiso para la operación.
Paso 6: Si todo está bien, la operación se ejecuta y ves los datos. Si algo falla, ves un error de acceso denegado.
Todo esto ocurre en milisegundos, cientos de veces mientras navegas por la aplicación.
Protecciones avanzadas
Microsoft ha añadido capas adicionales de protección que vale la pena conocer:
Acceso Condicional
Las políticas de acceso condicional en Entra ID permiten añadir reglas como "solo permitir acceso desde dispositivos corporativos" o "requerir MFA cuando se accede desde fuera de la oficina". Estas políticas se evalúan antes de que Dataverse siquiera vea la solicitud.
Token Protection
Una preocupación con los tokens es qué pasa si alguien los roba (por ejemplo, interceptando tráfico de red o accediendo a la memoria del navegador). Token Protection vincula el token criptográficamente al dispositivo específico que lo solicitó. Un token robado no funcionaría en otro dispositivo.
Evaluación Continua de Acceso (CAE)
Tradicionalmente, los tokens tenían una duración fija (por ejemplo, una hora). Si revocabas acceso a alguien, tenían hasta una hora para seguir usando su token existente.
CAE permite que cambios críticos (usuario deshabilitado, contraseña reseteada, ubicación sospechosa detectada) invaliden tokens inmediatamente, sin esperar a que expiren.
El misterio del caché de seguridad
Uno de los problemas más comunes que enfrentan los administradores: "Acabo de dar acceso a María pero sigue sin poder ver los registros". ¿Por qué?
La respuesta está en los cachés. Evaluar permisos es computacionalmente costoso. Imagina que Dataverse tuviera que recalcular todos los permisos de un usuario para cada clic que hace. El rendimiento sería terrible.
Para evitar esto, Dataverse cachea los resultados de seguridad. Cuando verificas los permisos de María la primera vez, el resultado se guarda. Las siguientes verificaciones usan el caché en lugar de recalcular.
Pero esto significa que cuando cambias algo (añades un rol, mueves a alguien de equipo, compartes un registro), el caché sigue teniendo la información vieja por un tiempo:
- Caché de roles: se invalida en aproximadamente 5-15 minutos
- Caché de equipos: similar, 5-15 minutos
- Caché de unidad de negocio: puede tardar hasta 15 minutos
La solución más rápida es pedir al usuario que cierre sesión completamente y vuelva a entrar. Esto fuerza la invalidación del caché de ese usuario. Si no, simplemente esperar unos minutos.
Puntos clave
- Microsoft Entra ID maneja la autenticación (quién eres) usando tokens JWT
- Dataverse maneja la autorización (qué puedes hacer) con roles y demás mecanismos
- El Acceso Condicional añade reglas adicionales antes de que Dataverse sea consultado
- Token Protection y CAE protegen contra ataques sofisticados
- Los cachés de seguridad pueden causar retrasos de 5-15 minutos en ver cambios
- Cerrar sesión y volver a entrar fuerza la invalidación del caché