← BACK

Case Study

Municipal Unified Identity Platform

Identity • Trust Boundaries • RBAC

View live site

Images

Gallery unavailable.

Overview

Centralized SSO-style authentication gateway for the Municipality of Bahía Blanca (autentica.bahia.gob.ar): citizens authenticate once and access 10+ critical municipal services with a single token. ~15k logins/month, 2 years uninterrupted in production. Identity is validated against national registries — ARCA, ANSES, RENAPER, and Mi Argentina — on every login; the gateway is the sole component that calls those APIs and the sole issuer of session tokens. Legacy systems consume signed tokens and enforce RBAC; they never re-authenticate. No PII in tokens; fail safe when national APIs are unavailable. Audit and RBAC at gateway and service layer.

Architecture & Design

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 as sole issuer of session tokens; legacy systems validate only
  • ADR-02No PII in tokens; minimal claims for authorization
  • ADR-03Fail safe when national identity APIs are unavailable
  • ADR-04RBAC enforced at gateway and at service layer
  • ADR-05Audit logging for authentication and token issuance

Scale & Constraints

Request volume
~45k logins/month; token validation on every request to downstream services.
Concurrency
Gateway is single writer for tokens; services are read-only validators. No distributed lock; stateless validation.
External dependencies
Mi Argentina, RENAPER, ARCA. Login depends on at least one being available; degraded mode (unverified session or reject) when all are down.
Failure modes
National APIs down or slow → degraded mode or login failure; no "verified" issued without verification. Token validation failure → 401; no fallback to legacy auth.
Data consistency
Session and verification state only in gateway; tokens are signed assertions. Services do not persist identity state; they validate and apply RBAC per request.

What was explicitly rejected

  • ✕

    Each legacy system calling national APIs and issuing its own tokens

    Would duplicate integration, PII exposure, and failure modes; single gateway gives one trust boundary and one place to fail safe.

  • ✕

    PII or raw registry data in tokens

    Blast radius and compliance; tokens are minimal claims (sub, roles, exp) so compromise of a service does not leak registry data.

  • ✕

    Long-lived tokens with no re-validation

    Verification must reflect current state; every login re-validates against national APIs so "verified" cannot become stale.