Alta y baja de cuentas federadas

El alta al vuelo (crear la cuenta en el primer inicio con una aserción válida) resuelve la entrada. La salida no tiene equivalente en el flujo: cuando la empresa cliente desactiva a alguien en su IdP, ese IdP deja de emitir aserciones para esa persona, pero el SP no recibe ningún mensaje. Todo lo que la persona tenga abierto o guardado en la aplicación sigue valiendo: una sesión larga, un token de API, una integración.

Por eso la baja necesita un canal propio. El estándar abierto para eso es SCIM 2.0 (RFC 7643 y 7644 del IETF, de 2015): el directorio del cliente le dice a la aplicación qué cuentas crear, cambiar o desactivar, y desactivar se expresa con el atributo active en falso. Sin SCIM queda la conciliación periódica contra una lista del cliente, que deja abierta la ventana entre lista y lista.

Lee aprovisionamiento.txt para saber cómo se dan de baja las cuentas de cada empresa y qué credenciales vencen. Después cruza retiros-corovita.txt con cuentas-corovita.txt: la fecha de retiro frente a la fecha y el medio del último acceso.

Una sesión larga es una credencial más. Si dura treinta días y no vuelve a preguntar al IdP, una persona que inició sesión la semana antes de irse puede seguir dentro tres semanas después de que su empresa la desactivó.

Para el informe hace falta el número exacto de cuentas que hay que cerrar hoy en el inquilino de Corovita: personas que ya no trabajan allí y cuya cuenta en Quenaré sigue activa, se hayan usado o no después del retiro.

La causa no es una persona que olvidó enviar una hoja: es un diseño en el que la baja depende de una hoja trimestral y en el que la baja, cuando llega, no alcanza a todo lo que la persona tiene abierto.