Cuando cae el proveedor de identidad

Para administrar el proveedor de identidad cuando este no funciona hace falta una puerta que no pase por él. Se resuelve con unas pocas cuentas de emergencia, creadas directamente en el sistema y no federadas. Como son una llave maestra, se guardan con cuidado: sus credenciales van en un sobre sellado o en una bóveda con acceso doble, cada uso se registra y se justifica con un ticket, y después de usarlas se cambian.

El error contrario también ocurre: dejar a todos los administradores solo con cuentas federadas, de modo que el día de la caída nadie pueda entrar a repararla.

El registro_idp guarda las horas de cada evento. La caída empieza cuando el monitoreo registra «caída» y termina cuando registra «restablecido». La alerta de las 08:41 es anterior: avisaba de un problema, pero las personas todavía podían entrar. Mide la caída en minutos.

La tabla dependencias dice qué aplicaciones dependen del proveedor y cuáles tienen un acceso alterno aprobado, por ejemplo una sesión ya abierta con vigencia o una vía de contingencia. Una aplicación que depende del proveedor y no tiene alterno es la que deja de funcionar completa durante la caída. Una que no depende del proveedor, como el sistema de acceso local, no se entera.

Se usaron dos cuentas de emergencia durante la caída. Usarlas era lo previsto. Lo que no puede faltar es el ticket que explique cada uso: sin él no se distingue una emergencia real de alguien que aprovechó el momento. La tabla cuentas_emergencia guarda el último uso de cada una y el ticket asociado.