CAPÍTULO 5 · Ver un botón no concede permiso
Reconocer a la persona antes de decidir qué puede hacer
La política responde qué acciones se permiten, pero necesita saber sobre quién está decidiendo. Crear otro sistema de cuentas puede no ser la mejor respuesta cuando la organización ya tiene un directorio y procesos para administrar identidades. Nuestro proyecto debe integrarse con esa realidad sin confundirla con las reglas particulares de SensorHub.
Introducimos el flujo de identidad externa y el papel de MSAL. Django participa en un intercambio que debe validar antes de establecer el contexto del usuario. Después de reconocerlo, la aplicación vuelve a su propia política para decidir capacidades. Un inicio de sesión exitoso no equivale a recibir automáticamente permiso de administración.
Más adelante configuraremos el registro, los entornos y los callbacks con detalle. Aquí queda clara la conexión entre identidad y autorización. Con ambas piezas podemos atribuir una operación a una persona, y eso abre otra necesidad: cuando una configuración cambie, el equipo deberá poder reconstruir qué ocurrió y con qué resultado.
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
Identidad externa, permisos propios
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
- Usuario. Inicia flujo de identidad
- Entra / MSAL. Adquiere contexto autenticado
- Adaptador. Resuelve identidad verificada
- Política local. Evalúa capacidades y objetos
01 / EL PROBLEMA
¿Para qué sirve?
Una cuenta corporativa confirma identidad externa, pero no necesariamente acceso a estaciones o configuración. Esa autorización sigue siendo local.
02 / COMPRENDER
El concepto, explicado
El flujo de código de autorización redirige al proveedor y vuelve a un callback. state vincula el retorno con la sesión que inició el flujo.
Usa una biblioteca oficial para intercambio y validación. No decodifiques un JWT y asumas que su contenido ya es confiable. Vincula tenant y identificador estable con una cuenta local habilitada.
03 / CONSTRUIR
Implementación paso a paso
- Registra una URI de callback exacta.
- Genera state aleatorio y de un solo uso.
- Intercambia el código con la biblioteca del proveedor.
- Vincula identidad validada y aplica política local.
04 / APLICAR
Ejemplo en SensorHub
# Esquema de control de state; no es un cliente MSAL completo.
import secrets
state = secrets.token_urlsafe(32)
request.session["auth_state"] = state
# Redirigir usando la biblioteca de identidad.
# En el callback:
expected = request.session.pop("auth_state", None)
received = request.GET.get("state", "")
if not expected or not secrets.compare_digest(received, expected):
raise PermissionDenied("Retorno de autenticación inválido.")Cómo leer el ejemplo
- El fragmento muestra una pieza del flujo; también se requiere intercambio de código, validación y sesión local.
- pop evita reutilizar state.
- El modo form_post puede exigir configuración de cookies distinta de un callback GET.
Error habitual
No guardes secretos en repositorio ni registres tokens en logs. Un correo puede cambiar; evalúa tenant + subject estable para vincular identidades.
05 / PRACTICAR
Tu turno
¿Puede un usuario externo autenticado modificar sensores sin rol local?
Ver solución orientativa
No. La identidad validada debe pasar además por can_manage_catalog o la capacidad equivalente.
06 / VERIFICAR
Cómo sabes que funciona
- Un callback repetido falla.
- Cuenta externa válida no concede privilegios automáticamente.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Auditoría y trazabilidad →Continuar en modo relato