Resumen ejecutivo
de desarrollo activo
orquestado por IA
de código, Java y TypeScript
automatizadas, ~420 de ellas de integración
de la API pública, documentadas en OpenAPI
de CI/CD hacia Kubernetes
El proyecto
Identix es un proveedor de identidad autoalojado. Una empresa lo instala en su propia infraestructura, y una sola instalación da servicio a muchas aplicaciones independientes (inquilinos), cada una con sus propios usuarios, roles, ajustes de inicio de sesión y claves de firma. Las contraseñas, las claves y los datos personales nunca salen de la infraestructura del operador.
La identidad es la parte más sensible de cualquier sistema desde el punto de vista de la seguridad: un error en este punto deja expuestas todas las aplicaciones que dependen de él. Por eso el proyecto debía combinar una funcionalidad amplia con una arquitectura de seguridad capaz de resistir un examen riguroso. Lo diseñó y construyó un solo ingeniero, que también se encarga de su mantenimiento.
Qué se construyó
Servidor de autorización: OAuth 2.0 y OpenID Connect sobre Spring Authorization Server, con un emisor y unas claves de firma propios para cada inquilino, rotación de los tokens de actualización y revocación inmediata de tokens.
- Aislamiento estricto entre inquilinos: cada solicitud queda confinada a su inquilino, y unas pruebas automatizadas de arquitectura garantizan el cumplimiento de esta regla
- Usuarios, roles, grupos y organizaciones, con importación y exportación masivas y una política de contraseñas por inquilino
- Autenticación de dos factores (TOTP) con códigos de recuperación
- Suplantación de usuarios auditada: un administrador puede actuar en nombre de un usuario, y cada una de esas sesiones queda registrada
- Webhooks firmados con HMAC para los eventos del ciclo de vida de los usuarios
- Registro de auditoría: propio de cada inquilino y en el que solo pueden añadirse entradas, con una vista de conjunto para el operador
- Exportación e importación de la configuración de inquilinos entre instalaciones
Consola de administración: React y TypeScript, en inglés y ruso, adaptable del ordenador al móvil y con un portal para desarrolladores integrado, que incluye guías de integración y documentación interactiva de la API.
API pública: 237 operaciones, descritas íntegramente en OpenAPI.
Infraestructura: tres servicios en Kubernetes con charts de Helm, PostgreSQL y Redis, y tres canalizaciones de CI/CD en GitLab que compilan, prueban y despliegan cada servicio. Si falla cualquier prueba, el despliegue se bloquea.
Seguridad desde el diseño
La arquitectura separa zonas de confianza. El servidor de autorización público no tiene acceso a la base de datos ni guarda claves privadas: todos los datos y la firma de todos los tokens residen en un servicio interno, accesible solo dentro del clúster. Las claves de firma se almacenan cifradas y solo se descifran en memoria, de modo que comprometer el nodo público no expone ni claves ni datos.
La seguridad formó parte del método; no se añadió a posteriori:
- Modelo de amenazas elaborado con STRIDE: activos protegidos, perfiles de atacante, límites de confianza y una contramedida para cada amenaza
- Documentación de seguridad para auditores, con los controles asignados a OWASP ASVS nivel 2 y a las buenas prácticas del IETF para OAuth 2.0 y JWT
- Auditoría de seguridad completada con éxito; todos los hallazgos se subsanaron
El método
Un solo ingeniero en el papel de arquitecto y orquestador de IA, con la metodología Specification-Driven Development. El trabajo partió de una especificación escrita (requisitos, modelo de datos, invariantes de seguridad), y cada decisión relevante quedó documentada en un registro de decisiones de arquitectura (ADR) antes de la implementación.
Los agentes de IA generaron código, pruebas y documentación a partir de esa especificación; el ingeniero revisó cada cambio, asumió la responsabilidad de la arquitectura y del modelo de seguridad y respondió de cada commit. La infraestructura (manifiestos de Kubernetes, charts de Helm, canalizaciones de CI/CD) la construyó la misma persona y del mismo modo.
El desarrollo no fue continuo: el proyecto avanzó por etapas, con pausas entre ellas. Contando solo los días en que realmente se trabajó, la plataforma requirió 40 días de trabajo.
Pila tecnológica
Comparación con el desarrollo tradicional
| Equipo tradicional típico (estimación) | Este proyecto (con IA) | |
|---|---|---|
| Plazo | 6–9 meses | 40 días de trabajo |
| Equipo | 4–6 ingenieros | 1 ingeniero |
| Infraestructura y CI/CD | Ingeniero DevOps aparte | Incluidas, mismo ingeniero |
| Seguridad | Modelo de amenazas y auditoría, a menudo aplazados | Modelo de amenazas STRIDE, auditoría completada |
| Documentación | Se redacta a posteriori, si acaso | Especificación y ADR desde el primer día |
| Pruebas automatizadas | Variable | ~1700 |
Conclusiones
La gestión de identidades y accesos no es un escaparate evidente para la entrega rápida: combina un amplio conjunto de funciones con requisitos de seguridad que no admiten concesiones. Identix demuestra que el método también funciona aquí.
Un ingeniero. 40 días de trabajo. Un servidor de autorización multiinquilino, una consola de administración, una API pública de 237 operaciones, unas 1700 pruebas automatizadas, Kubernetes y CI/CD, y una arquitectura de seguridad respaldada por un modelo de amenazas y una auditoría completada.
El factor decisivo no fue la velocidad de generación de código, sino la disciplina que la rodea: primero la especificación, las decisiones documentadas, cada cambio revisado. Eso es lo que hace que el sistema sea mantenible y lo que permitiría que otro equipo se hiciera cargo de él.