La identidad no llega dentro de la petición
Una aplicación de pagos recibe una solicitud firmada dentro de una sesión vigente. Su log dice user=elena@example.test. El equipo concluye que Elena aprobó el pago. Esa frase comprime una cadena que el log no muestra: quién asignó el correo, si todavía pertenece a la misma persona, qué cuenta resolvió la aplicación, qué autenticador se ligó a ella, cuándo se verificó, qué secreto mantiene la sesión, qué proceso actuó como intermediario y qué política autorizó ese pago concreto.
Cada eslabón puede ser correcto y la conclusión final seguir siendo excesiva. Una firma criptográfica válida puede verificar el autenticador equivocado si se ligó a otra cuenta. Una assertion auténtica puede pertenecer a otro emisor o audiencia. Una sesión puede continuar después de expirar la assertion que la originó. Una persona correctamente autenticada puede carecer de permiso sobre el recurso. Y un identificador estable dentro de un sistema puede colisionar con el mismo texto dentro de otro.
La identidad digital es, por ello, un sistema de relaciones. Este capítulo construye esas relaciones antes de estudiar contraseñas, MFA, autorización, tokens o federación en detalle. El objetivo no es memorizar un glosario: es poder reconstruir qué asociación estableció cada autoridad, qué evento la usó y qué evidencia permite sostener una atribución.
Sujeto, identidad y principal responden preguntas distintas
Un sujeto es aquello sobre lo que se hace una afirmación de identidad. En sentido general puede ser una persona, organización, dispositivo, servicio o proceso. Sin embargo, un estándar puede restringir el término: NIST SP 800-63-4 define subject como persona dentro de sus guías y distingue tres roles de esa persona: applicant, cuando se somete a identity proofing; subscriber, cuando está inscrita en el servicio; y claimant, cuando pretende autenticarse. Esa restricción importa: no se deben trasladar automáticamente requisitos para identidad humana a workloads o dispositivos. NIST SP 800-63-4, §3 y glosario
Una identidad digital es una representación contextual del sujeto. Contiene o referencia atributos: nombre, relación laboral, dispositivo administrado, tenant, estado contractual o cualquier propiedad pertinente al propósito. No todos esos atributos son identificadores; tampoco toda identidad necesita corresponder a una identidad civil verificada. NIST SP 800-63A-4 admite subscriber accounts sin identity proofing —por ejemplo, pseudónimas— siempre que se conserve ese estado. La existencia de una cuenta no prueba nombre legal, unicidad civil ni presencia física. NIST SP 800-63A-4, §5.1
Un principal es la identidad operativa bajo la que un sistema atribuye una interacción. RFC 4949 lo describe, en su uso general, como una identidad específica reclamada al acceder a un sistema; también reconoce usos particulares como el de Kerberos. En esta obra extendemos el modelo de forma explícita a personas, servicios, procesos y dispositivos, porque todos pueden ser actores de una decisión de seguridad. RFC 4949, entrada “principal”
La extensión no significa que todos sean equivalentes. En el vocabulario NIST de este capítulo, subject sin calificativo designa a la persona. Para procesos, servicios y dispositivos usamos actor técnico, proceso ejecutor o principal de servicio; esa extensión operacional se apoya en terminología general/RFC y queda fuera del alcance normativo de SP 800-63-4. Elena puede ser el subject humano, person-7319 una representación interna, payroll-2048 su subscriber account en el CSP, acct-772 su cuenta local en el RP, acct-772:approver el principal efectivo para aprobar y svc-payments el principal del proceso que media la operación. Una atribución profesional conserva iniciador, ejecutor y relación entre ambos.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Un identificador sólo identifica dentro de un alcance
Un identificador es un valor asignado para distinguir una identidad dentro de un namespace. El namespace incluye la autoridad que asigna valores, las reglas de unicidad, el tiempo durante el que se preservan y el contexto donde se interpretan. El texto 7319 no identifica nada por sí solo: puede ser un empleado en Northstar, una cuenta en el proveedor o el subject de un IdP.
Cuatro propiedades que suelen mezclarse deben evaluarse por separado:
- unicidad: ¿respecto de qué población y autoridad no se repite?;
- estabilidad: ¿puede cambiar o reasignarse con el tiempo?;
- resolución: ¿qué registro obtiene quien lo consulta?;
- control: ¿qué evidencia demuestra que quien lo presenta está autorizado a usarlo?
Un correo puede ser único hoy dentro de una organización, pero mutable y reasignable. Un nombre visible ni siquiera necesita ser único. Un UUID reduce la probabilidad de colisión bajo un método de generación, pero no aporta proofing ni control. Un número interno estable puede distinguir una cuenta sin revelar una identidad civil. Elegir identificador es, por tanto, elegir autoridad y política de ciclo de vida.
Elena cambia elena@example.test por elena.ruiz@example.test. Si la aplicación usa el correo como atributo de contacto, puede actualizarlo sin cambiar la cuenta. Si lo usa como clave primaria, cambia la identidad operativa. Si después reasigna el correo antiguo y la recuperación de cuenta confía sólo en ese canal, el nuevo titular puede resolver la cuenta histórica. El error no está en que el correo sea “malo”; está en atribuirle estabilidad, unicidad temporal y autoridad que su lifecycle no garantiza.
La federación hace visible el mismo problema. Para un IdP general, NIST SP 800-63C-4 define el federated identifier como la combinación lógica de un issuer identifier y un subject identifier. El RP no debe tratar sub=7319 como globalmente único entre IdPs: (idp-a, 7319) y (idp-b, 7319) son identidades federadas diferentes salvo un proceso adicional, autorizado y seguro de linking o resolución. NIST SP 800-63C-4, §3.4
Los atributos necesitan su propio alcance. department=finance puede haber sido asignado por recursos humanos, copiado al directorio, transformado por el IdP y almacenado por el RP. Que el valor coincida en los cuatro sitios no los convierte en una sola fuente ni garantiza igual frescura. Para usarlo en una decisión se necesita saber quién lo afirma, de qué fuente procede, cuándo se actualizó, con qué semántica y para qué propósito se permitió su divulgación. Un atributo puede describir al sujeto sin identificarlo de forma única; otro puede resolver una cuenta dentro de una población sin ser apropiado para mostrar al usuario.
Esta separación reduce también exposición. El RP no necesita recibir todos los atributos que conoce el CSP para distinguir una cuenta o decidir una acción. Compartir de más aumenta correlación entre servicios, impacto de filtración y riesgo de decisiones basadas en copias obsoletas. Minimizar no consiste en borrar contexto necesario, sino en entregar el conjunto justificado para el propósito y conservar procedencia suficiente para interpretarlo.
La cuenta es estado administrado, no la persona
Una cuenta conserva estado bajo una autoridad: identificadores, atributos, bindings, estado de alta o suspensión, historial y políticas. En el modelo de NIST, el Credential Service Provider (CSP) establece una subscriber account con información del subscriber y el inventario de authenticators ligados. Un RP federado puede mantener además una RP subscriber account, local al servicio y enlazada a uno o más federated identifiers. NIST SP 800-63-4, §3 NIST SP 800-63C-4, §3.8
Estas cuentas no son copias necesariamente idénticas. El CSP puede conocer evidencia de proofing y authenticators; el IdP puede añadir identificadores de federación; el RP puede mantener preferencias, roles y estado de negocio. Una baja laboral puede llegar primero al directorio, después al CSP y más tarde al RP. Decir “la cuenta está desactivada” sin nombrar cuál y cuándo oculta precisamente el intervalo de riesgo.
Tampoco debe suponerse una relación uno a uno. Una persona puede tener cuentas distintas para funciones separadas. Una cuenta de emergencia puede estar controlada por un equipo bajo ceremonia. Un principal de servicio puede representar múltiples instancias. Una cuenta compartida puede permitir operar, pero reduce atribución individual si no existe otro vínculo verificable. La arquitectura debe declarar esos cardinalities y no dejarlos implícitos en la palabra “usuario”.
Identity proofing no es login
Identity proofing establece confianza en que la evidencia y los atributos corresponden al sujeto que solicita inscripción. NIST SP 800-63A-4 separa resolución —encontrar una identidad candidata—, validación —comprobar autenticidad, vigencia y exactitud de evidencia/atributos— y verificación —demostrar que la evidencia corresponde al applicant—. El proceso crea o actualiza una subscriber account y registra qué métodos y nivel se alcanzaron. NIST SP 800-63A-4, §§2–4
Autenticación ocurre después: un claimant demuestra posesión y control de uno o más authenticators ligados a una subscriber account. Responde “¿controla ahora el medio que esta cuenta acepta para autenticarse?”, dentro del protocolo y assurance observados. No repite necesariamente el proofing. No demuestra que el endpoint esté libre de malware, que nadie haya delegado el authenticator, que la persona esté bajo ninguna forma de coerción ni que la cuenta deba poder ejecutar la acción solicitada. NIST SP 800-63B-4, introducción y glosario
Una cuenta creada tras confirmar un email puede ser perfectamente útil sin identidad civil. La afirmación correcta sería que se validó control del canal bajo la ceremonia observada, no que “la persona fue verificada”. A la inversa, un proofing fuerte realizado años atrás no prueba que el claimant actual controla legítimamente un authenticator no revocado. Assurance de identidad y assurance de autenticación responden preguntas diferentes.
Credencial, autenticador y binding no son el mismo objeto
El lenguaje cotidiano llama “credenciales” al par usuario–password y algunas APIs llaman credential a cualquier secreto. Ese uso local puede existir, pero un análisis necesita declarar la definición. NIST SP 800-63-4 usa credential para un objeto o estructura que enlaza autoritativamente una identidad —mediante un identificador y, opcionalmente, atributos— con al menos un authenticator poseído y controlado por el subscriber. La credential es emitida, almacenada y mantenida por el CSP; el subscriber puede poseer copias de información, por ejemplo certificados junto con sus claves. NIST SP 800-63-4, glosario “credential”
El authenticator es aquello que el subscriber posee y controla para autenticar la identidad del claimant: por ejemplo, un password memorizado o un módulo criptográfico, según el tipo. Su salida se verifica dentro de un protocolo. Un certificado público, una private key, el dispositivo que la guarda, la credential del CSP y la cuenta ligada son objetos relacionados, pero no intercambiables.
El authenticator binding establece la asociación entre un authenticator específico y una subscriber account. Esta asociación es una decisión de seguridad, no una consecuencia natural de que la criptografía funcione. Si Northstar liga la llave de Marco a la cuenta de Elena, una firma posterior puede ser matemáticamente válida y autenticar, conforme al registro, la cuenta equivocada. La causa es el misbinding.
El binding inicial durante enrollment pertenece al flujo de SP 800-63A-4 §4; el registro resultante y el inventario de authenticators pertenecen a la subscriber account descrita en §5. SP 800-63B-4 §4 gobierna el binding posterior al enrollment y los eventos de mantenimiento, pérdida, compromiso, duplicación, expiración, recovery e invalidación. Son ceremonias distintas y deben registrar quién autorizó la transición y desde qué sesión o proceso. El capítulo 39 estudiará la fuerza de tipos concretos; aquí importa el invariante: todo authenticator aceptado debe tener una asociación autorizada, observable y revocable con la cuenta correcta. NIST SP 800-63A-4, §§4–5; NIST SP 800-63B-4, §§4–4.2
Desliza horizontalmente para leer el diagrama a tamaño completo.
Del evento de autenticación a la sesión
Pedir el authenticator en cada interacción sería costoso y puede incentivar soluciones inseguras. Tras un evento de autenticación, el servicio puede crear una sesión: una relación temporal entre el software del subscriber —el session subject— y el servicio —el session host—. NIST SP 800-63B-4 basa su continuidad en un session secret que el host emite y el cliente presenta directamente o demuestra poseer mediante un mecanismo criptográfico. NIST SP 800-63B-4, §5
La sesión no es el authenticator original ni la credential. Es una nueva capacidad con lifecycle propio. Puede terminar por logout, inactividad, timeout absoluto o revocación; puede requerir reautenticación para prolongarse o para una acción sensible. En SP 800-63B-4 §5.1, los bearer session secrets no deberían persistir tras reiniciar la aplicación o el dispositivo, por lo que ese reinicio termina esas sesiones; un mecanismo proof-of-possession o device-bound puede persistir y sigue sujeto a sus timeouts y lifetimes. La sesión hereda como techo las propiedades de assurance del evento que la creó: puede tratarse como un nivel menor, pero no como uno superior.
Un session_id visible no necesariamente es el secreto: puede ser un handle opaco que referencia estado del servidor, o el valor puede portar estado protegido. En ambos casos, poseer un bearer session secret puede bastar para continuar la sesión. Por eso la observabilidad debe registrar una referencia no reutilizable, no el secreto. El capítulo 41 estudiará cookies, tokens, rotación y fijación; aquí basta separar tres preguntas:
- ¿qué evento y qué account originaron la sesión?;
- ¿qué software demuestra continuidad frente a qué host?;
- ¿qué acción permite todavía la política bajo el contexto actual?
La tercera pregunta evita un error común. Una sesión autenticada puede seguir activa mientras cambian el rol de Elena, el estado del pago o la separación de funciones. Si la aplicación sólo decidió autorización al crear la sesión, convierte información histórica en permiso presente. La autorización debe revaluarse con la granularidad y frescura que exija el recurso.
Tres dimensiones de assurance
La suite separa IAL, confianza en el proceso de identity proofing; AAL, confianza en el evento de autenticación y sus authenticators; y FAL, protección de la transacción federada entre IdP y RP. No son una escala única ni se sustituyen entre sí: un AAL alto no convierte una cuenta pseudónima en identidad civil verificada, y un IAL alto no fortalece una sesión mal protegida. Cuando una assertion comunica niveles, el RP debe interpretarlos dentro del trust agreement y su política, no como autorización automática. NIST SP 800-63-4, §3
Assertion, token y sesión: nombres que no se deben comprimir
Una assertion federada es una declaración verificable del Identity Provider (IdP) sobre una subscriber account para un Relying Party (RP). NIST SP 800-63C-4 §4.9 especifica su contenido, como issuer, audience, subject, tiempos, assertion identifier y protección criptográfica. Una firma válida sólo responde parte de la pregunta: también se debe confiar en el issuer para ese propósito, comprobar audience y tiempo, impedir replay cuando corresponda y resolver la cuenta correcta. NIST SP 800-63C-4, §4.9
Token sin calificativo no permite razonar. Puede nombrar un authenticator físico, un bearer access token, un ID token, una assertion serializada o un session token. Cada uno tiene emisor, audience, portador, presentación, binding, lifetime y función distintos. Este capítulo no adopta un formato concreto: exige que cualquier diseño complete esas propiedades antes de atribuir seguridad a “el token”.
En Northstar, Elena se autentica ante el IdP usando la subscriber account payroll-2048 del CSP. El IdP emite una assertion dirigida a la aplicación de pagos. La aplicación verifica la assertion, interpreta (issuer, subject) dentro del trust agreement, la enlaza con su cuenta local acct-772 y crea una sesión local. Sólo entonces su política decide si el principal efectivo acct-772:approver puede aprobar un pago.
La sesión del IdP, la ventana de validez de la assertion y la sesión local del RP son tres relojes distintos. SP 800-63C-4 §4.7 advierte que una sesión del RP puede sobrevivir a la assertion y que terminar la sesión del IdP no termina automáticamente las sesiones de RPs; §4.8 contempla señalización compartida cuando existe un acuerdo. Esos mecanismos deben diseñarse y verificarse, no inferirse. NIST SP 800-63C-4, §§4.7–4.8
Desliza horizontalmente para leer el diagrama a tamaño completo.
Autenticar un principal no autoriza una acción
La autorización decide si un principal puede realizar una acción sobre un recurso bajo condiciones. Llamamos policy decision point (PDP) al rol lógico que produce la decisión y policy enforcement point (PEP) al que la aplica; esos nombres no prescriben que deban ser dos servicios separados. Aquí sólo fijamos esa frontera. Las listas de control de acceso (ACL), el control basado en roles (RBAC), atributos (ABAC) o relaciones (ReBAC), la delegación formal, la separación de funciones y la arquitectura detallada de decisión se estudian en el capítulo 40.
Un login exitoso no responde “¿puede Elena aprobar este pago?”. Responde una pregunta más estrecha: el claimant demostró control de los authenticators ligados a la cuenta bajo el protocolo y condiciones observados. La autorización todavía debe resolver:
- principal efectivo y cualquier delegación;
- acción concreta, no sólo acceso a la aplicación;
- recurso y tenant exactos;
- estado actual del recurso;
- política y versión aplicables;
- condiciones como importe, región o separación de funciones;
- lugar donde se aplica el resultado.
Esta separación también limita el significado de los atributos. Que la assertion incluya department=finance no convierte al IdP en policy decision point del RP. El RP debe determinar procedencia, frescura y propósito del atributo y evaluar su propia política. El capítulo 40 comparará modelos de autorización; el invariante aquí es que identidad aporta contexto, no permiso universal.
También debe distinguirse delegación de impersonation. En una delegación explícita, un principal A actúa con facultades acotadas concedidas por B y el sistema conserva a ambos: actor y parte representada. En una impersonation, el sistema trata temporalmente a A como B o pierde esa distinción. Ambas pueden ser legítimas en una arquitectura concreta, pero tienen efectos distintos sobre autorización y auditoría. Un servicio que llama a otro “en nombre de Elena” no debe sobrescribir su principal técnico con el de Elena y borrar la cadena; tampoco debe registrar sólo al servicio y atribuirle la intención humana. Debe preservar quién inició, quién medió, qué autoridad delegó, qué alcance se concedió y dónde se aplicó.
El lifecycle real son varias máquinas de estado
Alta, cambio, recuperación, suspensión, revocación y terminación no son un único interruptor. La subscriber account, cada authenticator, cada federated binding y cada sesión mantienen estados propios. Una acción sobre uno puede —o no— producir señales para los demás.
Considérese una baja de Northstar:
- recursos humanos cambia el atributo laboral;
- el CSP suspende la subscriber account;
- el IdP deja de iniciar nuevas transacciones;
- los RPs reciben una señal o actualizan por sincronización;
- cada RP invalida bindings o sesiones según el acuerdo;
- los servicios reevaluan permisos y preservan registros según retención.
Si el paso 2 ocurre pero una sesión local continúa aceptándose, no basta afirmar “revocation falló”. Hay que identificar qué objeto se revocó, qué señal debía cruzar la frontera, qué latencia admitía la política y qué enforcement siguió aceptando el secreto. El remedio puede ser señalización, menor lifetime, introspección, reautenticación o evaluación continua; escogerlo pertenece al diseño de capítulos posteriores.
La recuperación merece la misma disciplina. Añadir un authenticator nuevo, resolver una cuenta por atributos o enlazar otro IdP modifica bindings de alta autoridad. Un atacante que supera recovery no necesita romper el authenticator anterior. Por ello la recuperación debe observarse como una transición privilegiada con prueba suficiente, notificación independiente, posibilidad de redress y revisión de sesiones existentes.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Qué debe registrar un sistema sin registrar secretos
El capítulo 18 cubre cuentas, procesos, credenciales y sesiones locales; el capítulo 20 cubre clocks, correlación, procedencia y límites generales del logging. Aquí no los reescribimos: conservamos únicamente el esquema específico que permite reconstruir bindings distribuidos entre CSP, IdP y RP.
Una auditoría útil reconstruye relaciones; una auditoría peligrosa copia capacidades reutilizables. No se deben almacenar passwords, private keys, authenticator outputs, assertions bearer completas ni session secrets en logs. La necesidad de correlación se satisface con referencias no reutilizables y procedencia.
Para una decisión approve payment, un evento puede conservar:
- identificador del evento, timestamp y fuente de reloj;
- issuer y subject identifier con minimización o pseudonimización apropiada;
- cuenta local del RP y principal efectivo;
- principal mediador o de servicio;
- referencia al evento de autenticación, assurance y recencia;
- handle de sesión no utilizable para continuarla;
- acción, recurso y tenant;
- atributos contextuales realmente usados;
- policy version y resultado del decision point;
- resultado del enforcement;
- request o trace ID y procedencia del productor.
La presencia de cada campo tampoco lo vuelve verdadero. Un header de identidad añadido por un cliente no tiene la procedencia de uno producido por un proxy autenticado; un subject copiado a través de varias colas puede quedar desactualizado; un timestamp sin reloj conocido dificulta ordenar eventos. El schema debe registrar quién produjo la afirmación y qué frontera la protegió.
La cadena resultante permite claims acotados. Por ejemplo: “A las 10:31 UTC, el RP verificó una assertion del issuer I para la audiencia R, resolvió (I,S) a la cuenta RP acct-772, creó la sesión H tras un evento AAL2 declarado y la policy P17 permitió al principal acct-772:approver ejecutar approve sobre payment-882; el PEP registró éxito”. No demuestra por sí sola que Elena estaba físicamente presente, que su endpoint era íntegro ni que nadie actuó con su consentimiento. Esos límites deben permanecer visibles.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Diagnosticar exige localizar la relación que falló
Cuatro incidentes pueden producir el mismo síntoma —una acción aparece bajo la cuenta de Elena— y requerir respuestas diferentes:
Colisión o reasignación de identificador. El authenticator y la sesión pueden ser legítimos para otra persona; falla el mapping. Se investiga namespace, historial y account resolution.
Misbinding de authenticator. La prueba criptográfica es correcta, pero el CSP ligó el authenticator a la cuenta errónea. Se investigan ceremonia, sesión que autorizó el binding, avisos e inventario.
Robo de session secret. El binding y la autenticación inicial fueron correctos; otra parte continúa la sesión. Se investigan emisión, transporte, storage, rotación, contexto y eventos posteriores.
Autorización obsoleta o incorrecta. El principal está bien atribuido, pero una policy antigua, caché o enforcement concede una acción indebida. Se investigan policy version, inputs, decision y aplicación.
Reducir los cuatro a “credenciales comprometidas” destruye la causalidad y favorece remediaciones cosméticas. Restablecer un password no corrige una colisión de namespace; revocar un authenticator no necesariamente termina sesiones; terminar sesiones no repara una policy; cambiar la policy no resuelve un binding indebido.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Síntesis: una identidad defendible es una cadena acotada
Un sistema no recibe una persona; recibe señales y objetos producidos por autoridades. El sujeto se representa mediante atributos. Una autoridad asigna identificadores dentro de un namespace. Una cuenta conserva estado. Una credential enlaza identidad y authenticator. Un claimant demuestra control en un evento de autenticación. Una assertion puede transportar ese resultado a otra frontera. Un host crea una sesión. Una política decide una acción para un principal y un enforcement la aplica.
La seguridad depende de que cada binding tenga autoridad, propósito, evidencia, lifecycle y revocación. También depende de no pedir a un eslabón lo que sólo puede demostrar otro: proofing no es autenticación; autenticación no es autorización; assertion no es sesión; identificador no es identidad global; log no es presencia física.
La pregunta profesional ya no es “¿quién es el usuario?”, sino una secuencia más precisa: ¿qué principal actuó, qué cuenta y namespace lo resolvieron, qué bindings sostienen esa atribución, qué evento mantiene la sesión, qué política autorizó la acción y qué límites conserva la evidencia? Esa secuencia será la base de los mecanismos concretos de los capítulos siguientes.