Aprovisionamiento y desaprovisionamiento con SCIM

El ciclo de vida de una identidad tiene tres momentos: alta (entra la persona), traslado (cambia de área o de cargo) y retiro. El diseño empieza por una decisión: cuál es la fuente de verdad de esos tres eventos. Casi siempre es el sistema de recursos humanos, porque es el único que sabe con autoridad que alguien entró, cambió de puesto o se fue. El directorio y el IdP reflejan lo que esa fuente dice; si cada uno crea o retira personas por su cuenta, aparecen identidades que nadie sabe de dónde salieron.

SCIM 2.0 es el estándar de la IETF para llevar esos cambios a las aplicaciones: un esquema común de usuarios y grupos (RFC 7643) y un protocolo sobre HTTP para crearlos, cambiarlos y retirarlos (RFC 7644), los dos de septiembre de 2015. El IdP o el directorio actúan de cliente y cada aplicación expone sus recursos /Users y /Groups.

El traslado es el momento que más se olvida. Un conector que agrega los grupos del área nueva pero no quita los del área anterior produce acumulación de permisos: con cada cambio de puesto la persona suma accesos, y al cabo de unos años puede aprobar en un área y revisar en otra lo que ella misma aprobó. La regla de diseño tiene dos mitades y las dos son obligatorias: dar lo nuevo y quitar lo viejo.

Abre el laboratorio y sigue el traslado de eventos-rrhh.txt en registro-scim.txt, conectores.txt y conciliacion.txt.

El protocolo ofrece dos formas de retirar: cambiar el atributo active a falso, que deja la cuenta sin acceso pero conserva su historia, o pedir el borrado con DELETE. La especificación permite que la aplicación no borre de verdad, pero desde fuera ya no se puede consultar el recurso. Qué hace cada aplicación con un DELETE lo documenta su proveedor, y esa respuesta pesa en el diseño: si la aplicación guarda registros que la empresa debe conservar, el borrado destruye evidencia que se necesitará después.

Lee las reglas de diseno-del-ciclo.txt y la columna de retiro de conectores.txt.

Ningún conector es perfecto: hay aplicaciones sin SCIM que dependen de un ticket y conectores que fallan y agotan sus reintentos. Por eso el diseño completo incluye una conciliación: comparar periódicamente las cuentas de cada aplicación con la fuente de verdad y tratar cada diferencia como un hallazgo. La conciliación es la que encuentra lo que el flujo automático dejó atrás.

Lee conciliacion.txt y cuenta solo lo que pide la pregunta.

Una de esas cuentas sigue activa porque el conector falló cuatro veces y dejó de intentarlo sin que nadie se enterara. Subir el número de reintentos no cambia el diseño: si el destino falla por horas, el conector se rendirá igual, solo que más tarde.