← VOLVER

Estudio de caso

Plataforma municipal de identidad unificada

Identidad • Límites de confianza • RBAC

Ver sitio

Imágenes

Galería no disponible.

Resumen

Gateway de autenticación estilo SSO para el Municipio de Bahía Blanca (autentica.bahia.gob.ar): los ciudadanos se autentican una vez y acceden a 10+ servicios municipales críticos con un único token. ~15k logins/mes, 2 años en producción ininterrumpida. La identidad se valida contra registros nacionales — ARCA, ANSES, RENAPER y Mi Argentina — en cada login; el gateway es el único componente que llama esas APIs y el único emisor de tokens de sesión. Sistemas legacy consumen tokens firmados y aplican RBAC; no re-autentican. Sin PII en tokens; fail safe cuando las APIs nacionales no están disponibles. Auditoría y RBAC en gateway y capa de servicio.

Arquitectura y diseño

Identity Trust Boundary Flow

Internal System

System Invariants

  • ·Tokens must not contain PII; only claims required for authorization (sub, roles, exp).
  • ·"Verified" is never issued when verification against national APIs did not succeed.
  • ·Only the gateway calls national APIs and issues tokens; services validate tokens only.
  • ·Session tokens are short-lived; re-validation on every login.
  • ·RBAC is enforced at gateway (route) and at service (resource); no bypass.
  • ·All authentication and token issuance events are logged for audit.

Architecture Decision Records

  • ADR-01Gateway como único emisor de tokens de sesión; sistemas legacy solo validan
  • ADR-02Sin PII en tokens; claims mínimos para autorización
  • ADR-03Fail safe cuando las APIs nacionales de identidad no están disponibles
  • ADR-04RBAC aplicado en gateway y en capa de servicio
  • ADR-05Auditoría de autenticación y emisión de tokens

Escala y restricciones

Volumen de requests
~45k logins/mes; validación de token en cada request a servicios downstream.
Concurrencia
El gateway es el único escritor de tokens; los servicios son solo validadores. Sin lock distribuido; validación stateless.
Dependencias externas
Mi Argentina, RENAPER, ARCA. El login depende de que al menos uno esté disponible; modo degradado (sesión no verificada o rechazo) cuando todos están caídos.
Modos de fallo
APIs nacionales caídas o lentas → modo degradado o fallo de login; sin 'verificado' emitido sin verificación. Fallo de validación de token → 401; sin fallback a auth legacy.
Consistencia de datos
Estado de sesión y verificación solo en el gateway; los tokens son aserciones firmadas. Los servicios no persisten estado de identidad; validan y aplican RBAC por request.

Qué se rechazó explícitamente

  • ✕

    Cada sistema legacy llamando a APIs nacionales y emitiendo sus propios tokens

    Duplicaría integración, exposición de PII y modos de fallo; un único gateway da un límite de confianza y un único punto de fail safe.

  • ✕

    PII o datos crudos de registros en tokens

    Radio de daño y compliance; los tokens son claims mínimos (sub, roles, exp) para que el compromiso de un servicio no filtre datos de registros.

  • ✕

    Tokens de larga vida sin re-validación

    La verificación debe reflejar el estado actual; cada login re-valida contra las APIs nacionales para que 'verificado' no quede desactualizado.