🌐 Federación de Identidades

🧠 Concepto clave

La federación de identidades permite a una organización aceptar y confiar en las identidades autenticadas por un proveedor de identidad externo (IdP). Es una evolución del inicio de sesión único (SSO) que va más allá de los límites de una red local o dominio.

📌 ¿Por qué es útil?
Porque en entornos reales, necesitas que empleados, socios, proveedores o clientes accedan a servicios corporativos sin tener que crear cuentas internas para cada uno.

🧩 ¿Cómo funciona la federación?

1. El principal (usuario) intenta acceder a un recurso (PS - proveedor de servicios).

Ej: un socio intenta acceder al portal de compras de tu empresa.

2. El proveedor de servicios (PS) lo redirige al proveedor de identidad (IdP).

Ej: Azure AD, Google, Okta, etc.

3. El usuario se autentica con el IdP (con su cuenta original externa).

Ej: Se loguea con sus credenciales de Google.

4. El IdP genera un claim o token firmado (ej: SAML, OAuth2/JWT).

Este token incluye atributos del usuario (nombre, rol, permisos…).

5. El principal presenta ese token al proveedor de servicios (PS).

El PS confirma la firma y validez del token (confianza mutua).

6. El usuario es autorizado a acceder según sus permisos.

✅ Sin necesidad de tener cuenta interna local.

📦 Aplicaciones y herramientas en uso real

Aplicación real Proveedor / Protocolo Uso
Autenticación Google a apps externas OAuth2 / OpenID Connect Login con cuenta Google
Login con Microsoft/Office365 Azure AD + SAML Acceso a apps empresariales federadas
Login con Facebook, Apple, Twitter OpenID Connect Federación de consumidores
Acceso B2B entre empresas ADFS, Azure AD B2B Partners acceden sin cuenta local
Login único en apps corporativas web Okta, OneLogin, Auth0 SSO federado multiempresa

🛠️ Protocolos comunes en federación

Protocolo Uso Notas
SAML 2.0 Web SSO empresarial Basado en XML. Muy usado en empresas
OAuth 2.0 Delegación de acceso a APIs Base para tokens de acceso modernos
OpenID Connect Autenticación web + APIs Capa de identidad sobre OAuth2
WS-Federation Integración con servicios MS antiguos Sucesor natural: SAML/OpenID Connect

🛡️ Qué hace cada equipo al respecto

🔴 Red Team

• Intenta interceptar o falsificar tokens de acceso o de identidad.

• Abusa de errores de validación en el proveedor de servicios (ej. token replay, malformado).

• Engaña al usuario para que inicie sesión en un falso IdP (phishing).

• Reutiliza sesiones federadas abiertas en ataques SSO Hijacking.

🔵 Blue Team

• Establece relaciones de confianza seguras entre IdP y PS (certificados, firma digital).

• Valida tokens y claims correctamente (aud, exp, issuer…).

• Aplica MFA en el IdP para asegurar autenticación fuerte.

• Supervisa logs de federación, alertas por token malformado o repetido.

• Aplica políticas como SCIM para sincronización y des-provisionamiento automático.

🟣 Purple Team → ¿Cómo se ataca y cómo se defiende?

Ataque Defensa
Reutilización de tokens (token replay) Verificación de expiración, anti-replay y scopes.
Suplantación de IdP (phishing) Validación estricta de issuer + MFA en IdP.
Claims falsificados o mal validados Validación rigurosa del token, firmas y claims.
Sesiones federadas persistentes Timeouts, rotación de tokens, detección de anomalías.

✅ Resumen práctico

Federación → Permite confiar en identidades externas sin necesidad de crear cuentas internas.
El usuario se autentica con su proveedor (Google, Azure, etc.), recibe un token firmado y accede a los servicios.
Se basa en protocolos como SAML, OAuth2 u OpenID Connect.
🔐 Es esencial en entornos multinube, B2B, aplicaciones SaaS y estrategias Zero Trust.

🧠 Esquema visual práctico

Federación de identidad
↓
Usuario accede a un proveedor de servicio (PS)
→ Redirige al proveedor de identidad (IdP)
→ IdP autentica al usuario y firma un token
→ Usuario presenta token al PS
→ PS verifica firma → autoriza acceso
→ Acceso concedido sin cuenta local
✅ Usado en entornos multiempresa, nubes híbridas y colaboración externa.

Proceso Detallado: Federación de Identidades

🔄 1. Confianza Federada Establecida (Trust Establishment)

• El proveedor de servicios (SP) y el proveedor de identidad (IdP) establecen una relación de confianza previa.

• Esta confianza se basa en firmas digitales, claves públicas/certificados.

• Se configuran endpoints, certificados y reglas de validación para que ambas partes acepten tokens mutuamente.

• 📌 Ejemplo: El portal de compras de tu empresa (SP) confía en los tokens emitidos por Azure AD (IdP).

👤 2. Inicio de Sesión del Usuario

• El usuario (principal) intenta acceder a una app (el SP).

• El SP detecta que el usuario no está autenticado.

🌐 3. Redirección hacia el IdP

• El SP redirecciona el navegador del usuario al IdP para realizar la autenticación.

• Este paso puede incluir parámetros como:

  • redirect_uri (dónde volver tras autenticarse)

  • scope, client_id, state, nonce, etc. (según el protocolo: SAML, OAuth2, OpenID Connect).

🔐 4. Autenticación en el IdP

• El usuario ingresa sus credenciales (ej. usuario/contraseña o MFA) en el IdP.

• El SP nunca ve estas credenciales.

• Si la autenticación tiene éxito, el IdP firma un token (SAML, JWT, etc.) con atributos del usuario.

🎫 5. Token de Reclamaciones Emitido

• El IdP devuelve al navegador del usuario el token firmado (assertion o claim token).

• Este token contiene:

  • Identidad verificada del usuario (ej. email, userID)

  • Tiempo de expiración (exp)

  • Atributos opcionales (ej. rol, permisos, grupo)

  • Firma digital del IdP

✅ 6. Validación y Autorización

• El navegador presenta el token al SP.

• El SP verifica la firma del token y la validez de los atributos (exp, aud, iss, etc.).

• Si todo es válido, el SP autoriza el acceso:

  • Puede asociar el usuario con una cuenta local.

  • Puede crear una sesión y asignar permisos según el claim recibido.

🎯 Resultado

• ✅ El usuario nunca escribe su contraseña en el SP.

• ✅ El SP confía en la autenticación del IdP.

• ✅ El acceso se gestiona de forma segura, escalable y externa.

✅ Resumen práctico

Federación de identidades → Proceso seguro donde el SP delega la autenticación a un IdP confiable.
El usuario se autentica en el IdP y recibe un token firmado que presenta al SP para acceder.
🔐 Ninguna contraseña es compartida con el SP.
Es ideal para entornos B2B, multiempresa, SaaS o Zero Trust.

🧠 Esquema visual práctico

1. Usuario accede a SP (Proveedor de Servicio) 

2. SP detecta que no hay sesión → Redirige al IdP (Proveedor de Identidad) 

3. Usuario se autentica en el IdP (MFA, contraseña, etc.) 

4. IdP emite un token firmado (claim/assertion) 

5. Usuario presenta token al SP 

6. SP valida firma y atributos → Concede acceso