Tema 6 de 6
Conceptos de identidad
Antes de hablar de Microsoft Entra hay que dominar el vocabulario: autenticación, autorización, proveedores de identidad, tokens, directorios y federación. El examen pregunta estos conceptos sin nombrar productos, así que conviene entender cómo funcionan por dentro.
Contenido
Autenticación y autorización
Autenticación (AuthN)
Probar que eres quien dices ser. Responde a ¿quién eres? Usa credenciales basadas en tres factores:
- Algo que sabes: contraseña, PIN
- Algo que tienes: teléfono, llave de seguridad, smart card
- Algo que eres: huella, rostro
Autorización (AuthZ)
Decidir qué puede hacer una identidad ya autenticada. Responde a ¿qué puedes hacer? Se basa en roles, permisos (leer, escribir, borrar) y atributos (departamento, ubicación).
Principio clave: privilegios mínimos, solo el acceso necesario para el trabajo.
Siempre en este orden
Primero la autenticación y después la autorización. Como en un hotel: muestras tu identificación en recepción (autenticación) y te dan una tarjeta que abre tu habitación y el gimnasio, pero no otras habitaciones (autorización).
Usar un solo factor es autenticación de un factor; la autenticación multifactor (MFA) exige dos o más factores de categorías distintas. Una contraseña más un PIN no es MFA: ambos son algo que sabes.
La identidad como perímetro de seguridad
Antes, firewalls y gateways VPN marcaban un perímetro de red y todo lo de adentro era confiable. Funcionaba cuando todos trabajaban en una oficina, con apps en servidores locales y dispositivos de la empresa. Hoy ese perímetro se erosionó por:
Apps en la nube y SaaS
Correo, colaboración y apps de negocio corren fuera de la red corporativa.
Trabajo remoto e híbrido
El tráfico desde casa o Wi-Fi pública puede no pasar nunca por el perímetro.
Dispositivos personales (BYOD)
Teléfonos y laptops que la organización no controla del todo.
Acceso de socios y clientes
Externos que necesitan recursos concretos sin entrar a la red interna.
Dispositivos IoT
Equipos conectados con credenciales e interfaces difíciles de administrar.
Un atacante que compromete una credencial de VPN o una cuenta en la nube salta el perímetro por completo. Una identidad es el conjunto de atributos que define a una persona, dispositivo o componente de software: para un usuario, su nombre de usuario, rol, permisos y métodos de autenticación; para un dispositivo, su ID de hardware, su inscripción y su cumplimiento.
La pregunta ya no es "¿esto viene de nuestra red?", sino "¿quién o qué hace la solicitud y debemos confiar en él?". Por eso la identidad es el nuevo perímetro de seguridad: toda decisión de acceso empieza por ella.
Tipos de identidad
👤 Humanas
Empleados, contratistas, clientes y socios que inician sesión en aplicaciones y datos.
💻 Dispositivos
Laptops, teléfonos, tablets y sensores IoT. Se pueden inscribir en administración, revisar su cumplimiento y confiar en ellos o restringirlos según su estado.
⚙️ Workload identities
Apps, servicios, contenedores y procesos automáticos que acceden a APIs, bases de datos y otros recursos sin una persona involucrada.
🤖 Agentes de IA
Agentes asistentes o autónomos que actúan por usuarios o procesos. Necesitan identidades diseñadas para ellos, más allá de las de aplicación, para autenticarlos, autorizarlos y gobernar su ciclo de vida a escala.
Las cuatro deben autenticarse y autorizarse: una credencial de aplicación comprometida da el mismo acceso que una cuenta de usuario comprometida, y un agente sin gobernar trae los mismos riesgos.
Los 4 pilares de una infraestructura de identidad
Gestionar identidades exige cubrir todo su ciclo de vida, no solo el inicio de sesión:
Administración
Crear, asignar, actualizar y eliminar identidades (provisioning cuando alguien entra, deprovisioning cuando se va) y definir las políticas para gestionarlas.
Autenticación
Verificar que la identidad es quien dice ser, pidiendo credenciales legítimas suficientes antes de dar acceso.
Autorización
Decidir qué puede hacer la identidad autenticada evaluando sus permisos y el contexto de la solicitud.
Auditoría
Registrar quién hizo qué, cuándo y desde dónde: logs de inicio de sesión, reportes, alertas y análisis forense. Clave para cumplimiento e investigación de incidentes.
El proveedor de identidad
Con la autenticación moderna, la autenticación y la autorización las presta un servicio central y dedicado: el proveedor de identidad (IdP). Crea y mantiene la información de identidad y ofrece servicios de autenticación, autorización y auditoría a las aplicaciones.
El usuario abre la aplicación
La app no gestiona contraseñas: lo redirige al IdP.
El IdP verifica las credenciales
Aplica sus políticas, por ejemplo MFA.
El IdP emite un token de seguridad
El cliente lo presenta de vuelta a la aplicación.
La app acepta el token
Confía en el IdP y usa la información del token para dar acceso.
Sin un IdP central
- Credenciales fragmentadas: una contraseña por app, reutilizadas y débiles
- Políticas inconsistentes de contraseñas y MFA
- Carga administrativa: cambiar el acceso app por app; cuentas olvidadas
Con un IdP central
- Políticas de autenticación, incluido MFA, iguales para todas las apps
- Monitoreo de inicios de sesión de todo el entorno
- Ciclo de vida completo: alta al entrar, baja al irse
Tokens, claims y protocolos
Un token de seguridad es un paquete estructurado de datos que emite el IdP. Lleva claims: piezas de información sobre la identidad, como su identificador único, nombre y correo, roles o grupos, cuándo se emitió y cuándo expira, y qué permite hacer.
ID token
Prueba de que el usuario inició sesión (autenticación). La app lo usa para saber quién es: nombre, correo, identificador.
Access token
Permiso para que la app acceda a un recurso concreto en nombre del usuario (autorización), como leer el calendario o llamar a una API.
Los tokens caducan para que uno robado no sirva para siempre, y el servidor los valida gracias a su relación de confianza con el IdP.
| Protocolo | Para qué |
|---|---|
| OpenID Connect (OIDC) | Autenticación en apps modernas de nube y móviles: verificar quién es el usuario y obtener su perfil básico. Construido sobre OAuth 2.0 |
| OAuth 2.0 | Autorización: obtener access tokens para acceder a recursos protegidos en nombre del usuario |
| SAML | Escenarios empresariales, integración de apps antiguas y federación entre organizaciones; común con identidad local |
Single sign-on (SSO)
Con SSO inicias sesión una vez en el IdP y entras automáticamente a todas las apps que confían en él, sin volver a escribir credenciales. Funciona porque cada app valida el token contra su relación de confianza con el mismo IdP.
Mejor experiencia
No hay que recordar una contraseña por aplicación.
Más seguridad
Menos avisos de credenciales: menos oportunidades de phishing y menos reutilización.
Control central
Desactivar la cuenta en el IdP quita el acceso a todas las apps de inmediato.
Microsoft Entra ID es un IdP en la nube con SSO para miles de aplicaciones; Google, Amazon, LinkedIn y GitHub también lo son. SSO ocurre dentro de un mismo IdP; cuando dos IdP distintos confían entre sí, se habla de federación.
Servicios de directorio y Active Directory
Un directorio guarda información de usuarios, dispositivos, grupos, políticas y aplicaciones; el servicio de directorio la pone a disposición. Active Directory Domain Services (AD DS), de Microsoft, es el más usado en redes locales: un servidor con AD DS es un controlador de dominio.
AD DS permite
- Una sola identidad por usuario en sistemas locales
- Group Policy para configurar equipos
- Autenticación con Kerberos y NTLM
- Unidades organizativas (OU)
Límites en un entorno moderno
- No autentica de forma nativa apps de nube y SaaS
- No administra iOS ni Android sin soluciones extra
- No soporta de forma nativa OAuth 2.0 ni OpenID Connect
- Fuera de la oficina requiere VPN
Microsoft Entra ID es la evolución en la nube: identidad como servicio (IDaaS), con autenticación moderna, multiplataforma y sin VPN. Conectado a AD DS forma una identidad híbrida.
Federación
La federación da acceso entre organizaciones o dominios mediante relaciones de confianza entre proveedores de identidad. Es como un pasaporte: tu país lo emite y otros lo aceptan sin darte una identificación nueva. El usuario inicia sesión con las credenciales que ya tiene y no necesita una cuenta nueva en la otra organización.
La organización A configura su IdP para confiar en el IdP de B
Es una decisión explícita de A.
Un usuario de B intenta entrar a un recurso de A
Se autentica en su propio IdP (el de B).
El IdP de A acepta esa autenticación
Y da acceso según la relación de confianza.
La confianza no es bidireccional por defecto
Si la organización A confía en B, B no confía automáticamente en A. La confianza en ambos sentidos se configura de forma explícita.
Colaboración B2B
Empleados de un socio entran a recursos compartidos con las credenciales de su empresa, sin que tengas que crear y gestionar cuentas de invitado una a una.
Proveedores sociales
Iniciar sesión en una app con tu cuenta de Google, Microsoft o GitHub. Reduce la fricción del registro en apps para clientes.
AD FS
Active Directory Federation Services: usuarios de AD local acceden a apps en la nube autenticándose contra un servidor AD FS que emite tokens que la nube acepta.
Escenarios de examen
| Situación | Concepto | Por qué |
|---|---|---|
| El usuario escribe su contraseña y aprueba una notificación en el teléfono | Autenticación multifactor | Combina algo que sabes con algo que tienes. |
| Un usuario autenticado puede leer pero no borrar un archivo | Autorización | Decide qué puede hacer una identidad ya verificada. |
| Una app obtiene permiso para leer el calendario del usuario | Access token (OAuth 2.0) | Autoriza el acceso a un recurso en nombre del usuario. |
| Una app necesita saber quién inició sesión | ID token (OpenID Connect) | Prueba la autenticación e identifica al usuario. |
| Al desactivar una cuenta, el empleado pierde acceso a todas las apps | SSO con un IdP central | Todas las apps confían en el mismo proveedor de identidad. |
| Empleados de un socio entran con las credenciales de su empresa | Federación (B2B) | Relación de confianza entre dos proveedores de identidad. |
| Usuarios de AD local acceden a apps en la nube vía un servidor local | AD FS | Federación de la identidad local hacia servicios en la nube. |
Trampas frecuentes del examen
❓ ¿Qué protocolo se usa para autorizar el acceso a un recurso en nombre del usuario?
OAuth 2.0. OpenID Connect se construye sobre OAuth 2.0 para la autenticación.
❓ Si A confía en B, ¿B confía en A?
No necesariamente. La federación no es bidireccional por defecto.
❓ ¿Cuál de los 4 pilares registra quién hizo qué y cuándo?
La auditoría. La administración se ocupa del ciclo de vida de las identidades.
❓ ¿Contraseña más PIN es MFA?
No. Ambos son "algo que sabes". MFA exige factores de categorías distintas.
❓ ¿Qué token usa una app para saber quién es el usuario?
El ID token. El access token sirve para acceder a recursos en su nombre.
❓ ¿SSO y federación son lo mismo?
No. SSO es iniciar sesión una vez en un IdP para muchas apps; la federación es confianza entre dos IdP distintos.
❓ ¿AD DS soporta de forma nativa OpenID Connect?
No. AD DS usa Kerberos y NTLM; la autenticación moderna la aporta Microsoft Entra ID.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Un usuario inicia sesión una sola vez y luego accede sin volver a escribir credenciales al correo, al CRM y a la intranet, porque todas confían en el mismo proveedor de identidad. ¿Qué capacidad describe esto?
¿Listo para poner a prueba "Conceptos de identidad"?
Preguntas originales, cada una con su explicación.
Empezar un simulacro