Access Management, SSO, MFA y flujos de autenticación modernos.
La base del stack de protocolos de IAM — qué es un servicio de directorio, el modelo de datos LDAP (DIT, DN, entradas, objectClasses, schema), los dominios y bosques de Active Directory, el salto a directorios cloud como Entra ID y Okta, la sincronización híbrida y por qué el directorio son las joyas de la corona de la empresa.
Cómo SAML 2.0 federa la identidad hacia apps web — los roles IdP/SP/usuario y el trust vía metadata XML, los flujos SP-initiated vs IdP-initiated, los bindings HTTP-Redirect/POST/Artifact, la anatomía de una SAML Assertion (Subject, Conditions, AuthnStatement, AttributeStatement), firma y cifrado, y cuándo SAML sigue siendo la opción correcta frente a OAuth/OIDC.
Cómo OAuth 2.0 permite que una app actúe en tu nombre sin tu contraseña — los cuatro roles, access vs refresh tokens, los grant types y cuándo usar cada uno (Authorization Code + PKCE, Client Credentials, Device Code, Refresh Token; los deprecados Implicit y ROPC), scopes y consentimiento, y qué cambia OAuth 2.1. Más el punto crítico: OAuth autoriza al cliente, no autentica al usuario.
Cómo OIDC convierte OAuth 2.0 en autenticación real — el ID token (JWT) vs el access token, claims estándar (sub, iss, aud, exp, email…), los endpoints de discovery (.well-known/openid-configuration) y UserInfo, validación con JWKS, los flujos Authorization Code/Hybrid/Implicit, y el logout front-channel, back-channel y RP-initiated.
Cómo SCIM 2.0 estandariza el aprovisionamiento de usuarios entre proveedores de identidad y apps — el modelo de recursos REST (User, Group, EnterpriseUser), los endpoints /Users, /Groups, /Bulk y /Schemas, las operaciones CRUD + Search + PATCH, cómo SCIM impulsa el ciclo JML y reemplaza scripts custom, y sus limitaciones reales con entitlements granulares y roles dinámicos.
Los bloques de construcción de los que dependen los protocolos — la estructura del JWT (header, payload, firma), tokens autocontenidos vs opacos/de referencia, JWE para payloads confidenciales, PASETO como alternativa más segura que evita la confusión de algoritmos, y cómo validar un token: firma, expiración, audiencia, emisor y revocación.
Los protocolos de identidad más allá de los cuatro centrales — los tickets Kerberos que aún autentican cada login de Active Directory, RADIUS detrás del Wi-Fi y las VPN corporativas, los legacy WS-Federation y WS-Trust basados en SOAP vivos en grandes estados de ERP, y la vanguardia resistente a phishing de FIDO2/WebAuthn/CTAP.
Cómo NIST SP 800-63 convierte '¿qué tan fuerte debe ser esto?' en tres diales independientes — IAL (prueba de identidad), AAL (fuerza del autenticador) y FAL (aseguramiento de federación) — cada uno con tres niveles, y cómo combinarlos para encajar con el riesgo de un caso de uso (por ejemplo, IAL2/AAL2 para banca).
Hacia dónde se dirigen los protocolos de identidad — asegurar microservicios y cargas de trabajo con OAuth token exchange (RFC 8693), DPoP (RFC 9449) y SPIFFE en el service mesh; evaluación continua de acceso vía CAEP y el Shared Signals Framework; y devolver a las personas el control de sus credenciales con credenciales verificables, DIDs y OpenID for Verifiable Credentials (OID4VCI/OID4VP).
Cómo se descompone toda decisión de acceso en tres etapas secuenciales — identificación, autenticación y autorización — y por qué la auditoría es un pilar transversal y no una cuarta etapa. Resolvemos la confusión de las '3 vs 4 A's'.
Las cinco categorías de factores de autenticación con sus implementaciones específicas (contraseñas, TOTP, push, FIDO2, biometría, contexto), la diferencia entre SFA/2FA/MFA, step-up authentication y autenticación adaptativa basada en riesgo (RBA).
Mecánica técnica de las implementaciones MFA más usadas — TOTP, SMS OTP, push, FIDO2/WebAuthn, passkeys, magic links — con sus flujos, vulnerabilidades concretas y patrones de fallback. Más CAPTCHA: por qué no es autenticación pero sí un complemento útil.
Una inmersión práctica en la autenticación biométrica: las modalidades principales, cómo funciona el matching, las métricas de error FAR/FRR/EER y el compromiso del umbral, liveness detection y anti-spoofing (PAD), cómo deben almacenarse los templates, las restricciones de privacidad y regulación (BIPA, GDPR Art. 9) y la biometría comportamental.
Cómo el Single Sign-On permite que una sola autenticación desbloquee muchas aplicaciones: la diferencia entre Web SSO, Enterprise SSO y Social SSO, los beneficios concretos para la UX y la postura de seguridad, el riesgo de 'romper la cadena' (blast radius) de un proveedor de identidad central, y por qué el Single Logout (SLO) es tan difícil que a menudo se ignora en silencio.
Cómo se construyen y defienden las sesiones web: atributos de cookie (HttpOnly, Secure, SameSite, Domain, Path), session tokens del lado servidor frente a JWTs y sus trade-offs, timeouts sliding frente a absolutos, idle timeout y re-autenticación forzada, cómo revocar realmente una sesión, y los controles contra CSRF, XSS y session hijacking.
Zero Trust como estrategia de seguridad, no como producto: los principios de NIST SP 800-207 (nunca confíes siempre verifica, asume la brecha, mínimo privilegio), la arquitectura Policy Decision Point / Policy Enforcement Point / Trust Algorithm, el Continuous Adaptive Trust que reevalúa la sesión durante toda su vida, por qué la identidad es el plano de control, y los mitos comunes.
El Control de Acceso Discrecional explicado: el modelo donde el dueño de un recurso decide quién más puede usarlo. La matriz de control de acceso de Lampson y sus dos proyecciones (ACLs y capabilities), los permisos de archivo de Linux y las ACL POSIX, las DACL de Windows, la debilidad del 'caballo de Troya' que hace que DAC gotee, y dónde el control discrecional sigue gobernando el mundo — desde los sistemas de archivos hasta compartir en Google Drive.
El Control de Acceso Obligatorio explicado: una política de todo el sistema basada en etiquetas de seguridad que ningún usuario — ni siquiera el dueño de un recurso — puede anular. Habilitaciones y clasificaciones de seguridad, el modelo Bell-LaPadula (no leer arriba, no escribir abajo) que cierra la brecha del caballo de Troya que DAC deja abierta, el espejo de integridad de Biba, y cómo SELinux, AppArmor y el Control de Integridad Obligatorio de Windows llevan el MAC de grado militar a los sistemas operativos cotidianos.
El Control de Acceso Basado en Roles explicado: el modelo que gobierna el acceso en la mayoría de las organizaciones agrupando permisos en roles que mapean a puestos. La indirección usuario-rol-permiso, el estándar NIST/INCITS 359 (núcleo, jerárquico, restringido), las jerarquías de roles y la separación de deberes, la explosión de roles y la minería de roles, y cómo aparece RBAC en los grupos de Active Directory, el IAM en la nube y Kubernetes — más exactamente dónde su ceguera al contexto fuerza el salto a ABAC.
El Control de Acceso Basado en Atributos explicado: decidir el acceso a partir de atributos del sujeto, el recurso, la acción y el entorno evaluados en el momento de la solicitud. El modelo NIST SP 800-162, cómo ABAC resuelve los problemas de acceso condicional que RBAC no puede expresar, el reto central de la gobernanza de atributos, la combinación de políticas y el problema de la consulta inversa, y por qué casi todo sistema moderno termina siendo un híbrido de roles y atributos en lugar de elegir uno.
El Control de Acceso Basado en Políticas explicado: convertir la política de autorización misma en un artefacto de primera clase, explícito y externalizado, escrito en un lenguaje formal y evaluado por un motor dedicado, en lugar de estar dispersa por el código de la aplicación. Cómo se relaciona PBAC con ABAC, el giro hacia la autorización externalizada y la política desacoplada del código, el ciclo de vida de la política de creación, prueba, versionado y revisión, y cómo OPA/Rego, AWS Cedar y XACML lo hacen real.
El Control de Acceso Basado en Relaciones explicado: derivar permisos de un grafo de relaciones entre entidades en lugar de roles o atributos aislados. Cómo ReBAC responde '¿estás conectado con este recurso de la forma correcta?', la tupla de relación y las reescrituras de userset en el corazón de Google Zanzibar, cómo una comprobación de permiso se vuelve un recorrido de grafo, los problemas de consistencia y rendimiento que Zanzibar tuvo que resolver, y el ecosistema que generó — OpenFGA, SpiceDB, Permify y Ory Keto.
El Control de Acceso de Nueva Generación explicado: el estándar NIST (INCITS 565, nacido de la Policy Machine) que modela usuarios, atributos, objetos y políticas como un único grafo dirigido y calcula el acceso como un camino de privilegio a través de él. Cómo las asignaciones, asociaciones, prohibiciones y obligaciones de NGAC subsumen RBAC, ABAC y ReBAC bajo un marco formal, cómo se deriva una decisión del grafo, en qué se diferencia de XACML, y por qué sus consultas de revisión eficientes y su evaluación determinista importan aunque la adopción sea aún temprana.
La arquitectura de referencia de XACML explicada desde los primeros principios: el patrón de cuatro componentes — Punto de Aplicación de Políticas, Punto de Decisión de Políticas, Punto de Información de Políticas y Punto de Administración de Políticas — sobre el que se construye prácticamente todo sistema de autorización. Aprende cada rol con una analogía sencilla, sigue una solicitud por todo el flujo de decisión, entiende los conjuntos de políticas, las reglas, los algoritmos de combinación y los cuatro valores de decisión, y descubre por qué el XML de XACML se apagó mientras su arquitectura triunfaba en todas partes.
Cómo los motores de autorización modernos escriben, prueban y despliegan la política que XACML dejó abstracta. Un recorrido profundo y cargado de diagramas por Open Policy Agent y Rego, AWS Cedar y Casbin — sus lenguajes, modelos de decisión, patrones de despliegue, ecosistemas (Gatekeeper, Conftest, Verified Permissions) y cómo probarlos y elegir entre ellos, con el mismo ejemplo práctico implementado en los tres.
Cómo el paper Zanzibar de Google convirtió la autorización en un problema de alcanzabilidad de grafos, por qué eso resuelve el acceso con forma de relación (grupos anidados, carpetas compartidas, permisos delegados) que los motores de políticas planas manejan mal, y cómo OpenFGA, SpiceDB y Ory Keto llevaron el modelo fuera de Google — incluyendo el problema del 'nuevo enemigo' de consistencia y cómo lo resuelven las zookies.
El espectro de granularidad en el que se ubica toda decisión de autorización, desde gateways perimetrales hasta comprobaciones por relación específica — qué cuesta cada nivel en latencia, esfuerzo de modelado y radio de impacto, cómo las arquitecturas por capas combinan comprobaciones gruesas y finas, por qué las comprobaciones ingenuas por elemento crean un problema de autorización N+1, y un marco de decisión para elegir la granularidad correcta por funcionalidad en lugar de por defecto.
Dónde corre realmente el PDP, hecho concreto: el patrón sidecar (Envoy ext_authz, OPA-Envoy, políticas de autorización de Istio/Linkerd), correr política en el borde de la CDN antes de que una solicitud llegue a tu infraestructura, WASM como la capa de portabilidad que permite ejecutar la misma política en todos estos lugares, y qué cambia sobre la distribución de política y el problema del nuevo enemigo una vez que el motor de decisión está repartido entre regiones y nubes en lugar de vivir en un solo lugar.
Un caso de estudio completo: llevar una aplicación de cashback concreta desde una lista de funcionalidades hasta autorización real y desplegada — clasificar cada funcionalidad en el espectro de granularidad, diseñar su modelo de roles RBAC y sus atributos ABAC, escribir la política real en Cedar, Casbin y OpenFGA para cada funcionalidad, decidir dónde corre cada comprobación, y probar todo en CI. Cada marco de este módulo, aplicado a un sistema, de principio a fin.