CAPÍTULO 7 · La identidad sale del equipo
Entender la alternativa antes de mezclarla con nuestra elección
Al abrir App Service encontramos opciones de autenticación que parecen resolver el mismo problema que acabamos de configurar. Es fácil pensar que activarlas agrega una protección equivalente sin alterar el recorrido. Sin embargo, cambian quién conduce el ingreso y qué información recibe la aplicación después.
Easy Auth permite situar la autenticación en la plataforma. Lo estudiamos como una alternativa a la ruta principal del equipo, no como un paso obligatorio que sigue a MSAL propio. Su callback pertenece al mecanismo de la plataforma y no se intercambia con la vista de retorno de Django. Conocer esa diferencia evita configurar dos recorridos como si fueran uno solo.
La comparación nos permite justificar la elección actual sin descartar otros escenarios. Para que la alternativa se comprenda de verdad, veremos qué habría que configurar si se escogiera. Después volveremos al problema común a ambas rutas: cómo administrar quién puede entrar y con qué alcance.
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
Autenticar antes de llegar a Django
El flujo de autenticación sale a Entra y vuelve a la plataforma antes de Django. El mapa resume responsabilidades, no el detalle de redirecciones HTTP.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Cliente. Solicita acceso
- Easy Auth. Controla autenticación en plataforma
- Entra ID. Autentica al usuario
- Django. Recibe contexto y evalúa negocio
01 / EL PROBLEMA
¿Para qué sirve?
Una aplicación empresarial puede necesitar autenticar usuarios sin mantener un login propio en Django. App Service ofrece una capa gestionada para ese ingreso.
02 / COMPRENDER
El concepto, explicado
Este tema es el recorrido alternativo Easy Auth. Solo configures el proveedor Microsoft en App Service Authentication cuando elijas que la plataforma autentique. Si sigues MSAL propio, mantén Authentication desactivado y continúa con el callback de Django.
Easy Auth se ejecuta antes de la aplicación y puede redirigir al proveedor o rechazar una petición anónima. Debes elegir expresamente el comportamiento; permitir anónimos no protege automáticamente todos los endpoints.
Django recibe contexto de identidad mediante las cabeceras documentadas por la plataforma. Esa confianza requiere que las solicitudes solo lleguen por la capa que autentica y controla dichas cabeceras.
Easy Auth no crea automáticamente request.user de Django ni aplica tu política por sensor. Un adaptador debe construir el actor y mapear capacidades cuando la aplicación lo necesite.
Para una web privada una redirección puede ser apropiada; una API suele necesitar 401. En esta academia pública no activamos esa barrera: la lección explica su uso en otros proyectos.
03 / CONSTRUIR
Implementación paso a paso
- Dibuja el límite de confianza entre cliente, plataforma y aplicación.
- Decide qué páginas son públicas y qué API requiere identidad.
- Configura el proveedor y el comportamiento para solicitudes no autenticadas.
- Crea un adaptador de identidad usando el contrato oficial, con rechazo de contexto inválido.
- Prueba acceso por el camino autorizado y cualquier ruta alternativa a la aplicación.
04 / APLICAR
Ejemplo en SensorHub
# Contrato ilustrativo para el adaptador, NO validador de tokens.
from dataclasses import dataclass
@dataclass(frozen=True)
class VerifiedActor:
tenant_id: str
object_id: str
capabilities: frozenset[str]
# Un middleware propio construye este actor SOLO tras verificar
# el origen confiable y el contexto autenticado de la plataforma.
# request.actor = identity_adapter.from_trusted_platform(request)Cómo leer el ejemplo
- La clase explicita los datos que consumen servicios y políticas.
- No hay una lectura directa de headers del cliente presentada como validación.
- No se instala este middleware en la academia pública.
Error habitual
Decodificar X-MS-CLIENT-PRINCIPAL en un servidor accesible directamente y tratar su contenido como prueba de autenticación.
05 / PRACTICAR
Tu turno
Diseña dos pruebas negativas para una API empresarial detrás de Easy Auth.
Ver solución orientativa
Envía una llamada sin identidad válida y otra con cabeceras fabricadas por un cliente. Ambas deben ser rechazadas. Añade una identidad válida sin capacidad y exige denegación de negocio.
06 / VERIFICAR
Cómo sabes que funciona
- La API no devuelve HTML de login como si fuera JSON.
- El actor procede del límite confiable.
- Los permisos se verifican en el backend.
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:
Configurar Easy Auth por App Service →Continuar en modo relato