Iniciamos sesión en nuestra propia consola de admin con nuestro propio SAML. Esto es lo que cazó.
Existe una versión del dogfooding que es un eslogan, y una versión en la que tus propios empleados no pueden desplegar código hasta que el fallo esté resuelto. Nosotros practicamos la segunda. La consola del personal de Authagonal, la que usamos para gestionar cada tenant, se autentica a través de Authagonal mismo: SAML single sign-on desde nuestro directorio Entra, con SCIM decidiendo quién entra y qué puede hacer. No hay una tabla aparte de contraseñas de admin. La borramos. Si nuestro propio SAML se rompe, quedamos fuera de nuestro propio producto.
Eso resulta incómodo justo de la manera útil. Convierte el "el SSO es una función enterprise que soportamos" en "el SSO es la única forma en que la gente que construyó esto puede trabajar hoy." Esto es lo que cazó el hecho de ser nuestro propio cliente.
Un build recortado que rompió la verificación de firma
Publicamos el servidor de auth recortado, para mantener la imagen pequeña. El trimming elimina de forma agresiva el código cuyo uso no puede demostrar, y la reflexión le oculta ese uso. .NET resuelve sus algoritmos criptográficos de firma XML por nombre, de forma reflexiva, a través de CryptoConfig. El trimmer no pudo ver que esos tipos eran necesarios, los eliminó, y SignedXml se quedó en silencio incapaz de construir el algoritmo. La verificación de firma SAML, el paso que demuestra que el inicio de sesión es real, lanzó una referencia nula en tiempo de ejecución.
Las pruebas unitarias pasaban, porque se ejecutaban contra el build sin recortar donde los tipos aún existían. Solo fallaba el artefacto de producción recortado, y fallaba en el momento exacto en que una persona intentaba iniciar sesión. Ahora desplegamos el servidor de auth sin recortar, con una sana desconfianza hacia recortar cualquier cosa cercana a la criptografía basada en reflexión. Si solo soportáramos SAML en lugar de vivir de él, esto sería el informe de incidente de un cliente en vez del nuestro.
El provisioning es el verdadero login
Autenticar a un usuario es la mitad fácil del SSO. La mitad difícil es decidir qué tiene permitido hacer y mantenerlo sincronizado a medida que la gente entra y sale. Eso lo gobernamos con SCIM: la pertenencia a grupos de Entra se mapea a roles, resuelta en el momento exacto en que se emite un token, no copiada una sola vez al crear la cuenta. Añade a alguien al grupo correcto y tendrá acceso en su siguiente inicio de sesión; quítalo y el acceso desaparece. Nuestra propia lista de acceso hace dogfooding con exactamente el mapeo de grupo a rol que entregamos.
Ese cableado saca a la luz una clase de fallo que solo existe cuando la autenticación y la autorización viven en dos sistemas distintos: un admin recién provisionado podía autenticarse antes de que su rol hubiera aterrizado del todo, dejando el primer inicio de sesión en un estado válido pero no autorizado. La solución está en el orden del provisioning, no en el login, y solo la encuentras siendo el nuevo admin que inicia sesión por primera vez.
Un 500 que debería haber sido un 403
El fallo más pequeño fue el más vergonzoso. Cuando un usuario autenticado llegaba a algo que no tenía permitido, la API devolvía un 500 en lugar de un 403 limpio, porque la ruta de código que emite la respuesta "prohibido" dependía de un servicio que no estaba cableado en ese host. Una petición denegada se supone que es un resultado tranquilo y esperado, no un error del servidor. Invisible hasta que eres tú al que le deniegan.
La frontera que más nos importa
Por debajo de todo esto está la única regla que una plataforma de identidad multi-tenant no puede permitirse fallar: un tenant nunca debe convertirse en nuestro admin. No confiamos en una sola comprobación. La plataforma es su propio issuer y un tenant no puede reclamar su slug; la clave de firma de la plataforma es distinta de la de cada tenant, de modo que un token firmado para un tenant no puede reutilizarse como un token de plataforma; y el store de la plataforma impone los roles de plataforma de forma independiente. Tres cerrojos, porque el coste de que uno solo falle abierto es el producto entero.
El punto
Ninguno de estos fue cazado por una prueba ingeniosa. Los cazó una persona que intentaba hacer su trabajo y no podía. Ese es el argumento para usar tu propio producto a la profundidad en la que puede hacerte daño: convierte los fallos escondidos en las grietas entre sistemas en fallos que resuelves antes del desayuno, porque no puedes desplegar hasta hacerlo.
Todo aquello en lo que se apoya nuestra consola (SSO, SAML, SCIM, MFA, registros de auditoría) está incluido en cada plan de Authagonal, sin bloquearlo tras un nivel ni cobrarlo por conexión. Mira qué se incluye.