CAPÍTULO 7 · La identidad sale del equipo
Pertenecer a la organización no concede acceso a todo
El directorio y los nombres nos ayudan a reconocer usuarios y recursos, pero no sustituyen una decisión de acceso. Una persona puede necesitar una aplicación sin necesitar otra; una cuenta válida puede intentar una acción fuera de su responsabilidad. Si equiparamos pertenencia con permiso general, la política local que construimos pierde su sentido.
Aplicamos una verificación explícita del acceso y limitamos privilegios al trabajo necesario. La identidad establece quién participa; el recurso y la acción determinan qué debe evaluarse después. Este criterio conecta la política de SensorHub con las decisiones de infraestructura, sin suponer que una frontera de red resuelve por sí sola todo el problema.
Con esa orientación podemos entrar en la configuración concreta del login. Elegimos primero quién conducirá el flujo, porque esa decisión afecta los callbacks y la forma en que el proyecto podrá trasladarse a otro alojamiento. En la experiencia del equipo, la ruta principal es MSAL dentro de Django.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Verificar en cada límite de confianza
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Identidad. Verifica quién solicita
- Asignación. Controla ingreso corporativo
- Permiso. Autoriza acción y objeto
- Evidencia. Registra decisiones sensibles
01 / EL PROBLEMA
¿Para qué sirve?
Un usuario correctamente autenticado puede intentar modificar sensores de otra organización. El login no responde por sí solo qué datos y acciones están autorizados.
02 / COMPRENDER
El concepto, explicado
Zero Trust propone verificar explícitamente, usar privilegios mínimos y asumir posibles compromisos. Una lista de productos activados no demuestra por sí sola que el sistema cumpla esos principios.
Entra B2B gestiona invitados; las políticas de identidad pueden exigir MFA. La asignación a la Enterprise Application controla el acceso corporativo cuando se exige asignación, con sus excepciones y licencias correspondientes.
Django sigue evaluando capacidad, organización y objeto en cada caso de uso. PostgreSQL conserva datos y trazabilidad, pero no sustituye la política de autorización.
MSAL y Easy Auth son alternativas para gestionar autenticación según el diseño. Evita dos flujos superpuestos sin un contrato claro sobre quién valida identidad y crea el contexto del usuario.
03 / CONSTRUIR
Implementación paso a paso
- Define amenazas: cuenta comprometida, token de otra audiencia y acceso entre organizaciones.
- Selecciona un mecanismo de autenticación y configura políticas de identidad aplicables.
- Exige asignación donde corresponda y prueba usuarios asignados y no asignados sin roles privilegiados.
- Resuelve la identidad por identificadores estables como tenant y object ID, no por un email editable.
- En el backend aplica política sobre acción y objeto; registra decisiones sensibles sin guardar tokens.
04 / APLICAR
Ejemplo en SensorHub
# Esquema del servicio, dependencias a implementar en tu proyecto.
def change_threshold(actor, sensor, value, policy, audit):
policy.require(actor, "sensor.configure", obj=sensor)
old_value = sensor.threshold
sensor.threshold = value
sensor.save(update_fields=["threshold"])
audit.record(actor=actor, action="threshold.changed",
object_id=sensor.pk, before=old_value, after=value)Cómo leer el ejemplo
- El servicio recibe un actor ya validado; no decodifica tokens por su cuenta.
- La política debe comprobar también pertenencia y alcance del sensor.
- Persistencia y auditoría deben coordinarse en una transacción cuando sean parte de la misma operación.
Error habitual
Permitir la acción porque se recibió un email corporativo o porque el usuario pasó MFA.
05 / PRACTICAR
Tu turno
Un supervisor de la organización A solicita editar un sensor de B. Diseña la respuesta y la evidencia.
Ver solución orientativa
La política deniega por alcance de objeto aunque el rol permita editar sensores. Se responde sin exponer datos de B y se registra identidad, acción, identificador y razón de denegación.
06 / VERIFICAR
Cómo sabes que funciona
- MFA no otorga permisos de negocio.
- El acceso entre organizaciones se deniega.
- Los eventos de auditoría no contienen tokens ni secretos.
Para profundizar
Documentación oficial para comprobar configuración, permisos y condiciones vigentes. Revisión del tema: 2026-10-11.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
MSAL propio en DEV y PROD: registro y callback →Continuar en modo relato