¿Cómo diseñarías un servicio de aprovisionamiento SCIM 2.0 confiable?

Pregunta y escenario

Un cliente empresarial utiliza tu SaaS como proveedor de servicios y su proveedor de identidad envía cambios de usuarios y grupos. Las solicitudes pueden duplicarse, desordenarse, retrasarse o reintentarse tras un tiempo de espera agotado. El servicio debe admitir inquilinos (tenants), identificadores externos, pertenencia a grupos, borrado suave (soft delete), auditabilidad y revocación inmediata, preservando al mismo tiempo la semántica de recursos y errores de SCIM 2.0.

Qué evalúa el entrevistador

• ¿Entiende el candidato la semántica de User, Group, schemas, filtrado y PATCH de SCIM?
• ¿Puede conectar el mapeo de recursos externos, las claves de idempotencia, las actualizaciones concurrentes y los reintentos en un solo flujo de datos?
• ¿Distingue entre active=false, solicitudes de eliminación y revocación de sesiones de la aplicación?
• ¿Puede aplicar el aislamiento de inquilinos, el alcance de tokens, la auditoría, los límites de tasa (rate limits) y la protección de campos confidenciales?

Preguntas aclaratorias para hacer primero

Confirma si el proveedor de identidad es la fuente de verdad para los perfiles, si los grupos se envían mediante push, si se permite la eliminación definitiva (hard delete), los objetivos de latencia de sincronización y la escala de inquilinos. Aclara si el userName externo es estable, si ocurren cambios de correo electrónico, los límites de tamaño de grupo, el soporte masivo (bulk) y con qué rapidez deben expirar las sesiones existentes tras la desactivación. No utilices el correo electrónico como clave primaria inmutable.

Un marco de respuesta de 30 segundos

Almacena los recursos externos de SCIM y las cuentas locales en un mapeo con alcance de inquilino, manteniendo los identificadores externos estables separados de los ID internos. Haz que las operaciones de creación, actualización, PATCH, eliminación y consulta sean idempotentes con huellas digitales de solicitud y versiones; rechaza explícitamente las escrituras obsoletas. active=false activa la desactivación y la revocación de sesiones, mientras que la eliminación sigue una política de retención del inquilino. Cada solicitud valida el inquilino, el alcance del token y el contexto de auditoría, y los efectos asíncronos reintentables no deben otorgar permisos por duplicado.

Análisis detallado paso a paso

1. Definir los límites de los recursos. Expón las capacidades SCIM que realmente admitas, como /Users, /Groups, /ResourceTypes, /Schemas y /ServiceProviderConfig. Mantén schemas coherente con cada tipo de recurso y devuelve errores normalizados para los filtros no admitidos.
2. Construir el mapeo de identidades. Por cada inquilino, almacena el ID de recurso externo, el ID de usuario local, el sistema de origen y la versión actual. Los campos mutables como userName y el correo electrónico son para búsqueda o visualización, no para reemplazar el mapeo estable; los conflictos requieren revisión en lugar de fusiones silenciosas.
3. Implementar idempotencia y control de concurrencia. Un POST repetido devuelve el recurso existente o se reproduce de forma segura a partir de una huella digital de la solicitud. Aplica las operaciones PATCH individualmente y registra los resultados. Cuando sea compatible, exige una condición de ETag o de versión para que las escrituras obsoletas no puedan sobrescribir datos más recientes.
4. Gestionar el ciclo de vida de usuarios y grupos. active=false revoca los permisos de la aplicación, bloquea nuevos inicios de sesión y expira las sesiones actuales. La eliminación definitiva sigue las reglas de retención y auditoría. Actualiza la pertenencia a grupos mediante la diferencia de conjuntos; un fallo parcial no debe eliminar a todos los miembros que no fueron confirmados.
5. Aislar los efectos asíncronos. Después de que la API escriba en una tabla de hechos local, encola la sincronización de permisos, las notificaciones de bienvenida y los eventos de auditoría. Los mensajes llevan el inquilino, la versión del recurso y la clave de idempotencia; los consumidores duplicados no pueden otorgar acceso ni enviar notificaciones dos veces.
6. Proteger y operar el servicio. Los tokens SCIM se limitan a un inquilino y a un alcance de operación, con rotación, revocación y expiración. Delimita la paginación, los filtros y los tamaños de operaciones masivas. Registra el éxito, el rechazo, los conflictos, los reintentos y la latencia de desactivación sin registrar tokens completos ni atributos confidenciales.

Ejemplo de respuesta de alta calidad

Trataría la API SCIM como el límite de sincronización desde una fuente de identidad externa hacia las cuentas locales. Cada inquilino obtiene su propio token, mapeo de recursos y registro de auditoría. Los recursos User y Group conservan identificadores externos e internos estables y siguen el esquema SCIM. Los filtros no admitidos, las operaciones PATCH o las reglas de retornabilidad generan errores explícitos en lugar de suposiciones.

Las escrituras se registran primero en una tabla de hechos local y luego encolan efectos de permisos reintentables por versión de recurso. Los ID externos, las huellas digitales de solicitudes y las versiones condicionales hacen que los reintentos sean idempotentes; las versiones obsoletas no pueden sobrescribir datos nuevos. active=false revoca permisos, bloquea nuevos inicios de sesión y expira sesiones, mientras que la eliminación sigue la retención. Las actualizaciones de grupos utilizan diferencias de conjuntos y reintentan fallos parciales sin borrar miembros no confirmados. Se observa la latencia de sincronización por inquilino, los conflictos, el tiempo entre la desactivación y la expiración de la sesión, y las colas de mensajes no entregados (dead letters). Las referencias incluyen RFC 7643, RFC 7644 y la guía de implementación SCIM de Okta.

Errores comunes

• Implementar únicamente POST /Users sin /ServiceProviderConfig, filtros, PATCH, tipos de error y paginación.
• Usar el correo electrónico como la única clave, creando duplicados o vinculando la cuenta incorrecta tras un cambio de nombre.
• Tratar un reintento por tiempo de espera agotado como un comando nuevo y otorgar permisos, enviar notificaciones o sobrescribir campos más recientes por duplicado.
• Ocultar a un usuario tras active=false sin revocar tokens, permisos ni sesiones actuales.
• Borrar todos los miembros del grupo local tras un fallo de sincronización parcial, convirtiendo un problema transitorio de red en una pérdida generalizada de acceso o en una concesión excesiva de permisos.

Preguntas de seguimiento y respuestas

¿Qué ocurre si el proveedor de identidad repite la misma solicitud de creación?

Busca el inquilino y el ID de recurso externo y conserva una huella digital o versión de la solicitud. Devuelve una representación estable para un recurso existente; si el payload entra en conflicto, devuelve un error diagnosticable y audítalo en lugar de sobrescribir silenciosamente un cambio local.

¿Cómo se preserva la continuidad de la cuenta tras un cambio de correo electrónico?

Utiliza el mapeo estable entre el ID de recurso externo y el ID de cuenta local, tratando al correo electrónico como un atributo mutable. Comprueba la unicidad a nivel de inquilino, actualiza los alias de visualización e inicio de sesión, y nunca crees una cuenta nueva ni hagas coincidencias entre inquilinos mediante el correo electrónico.

¿Cómo mantener la seguridad cuando la desactivación y el inicio de sesión llegan al mismo tiempo?

La autorización lee un estado de cuenta linealizable o una versión de revocación. La desactivación avanza la versión y revoca las sesiones; el inicio de sesión la comprueba de nuevo antes de emitir credenciales y rechaza una cuenta desactivada, incluso si una tarea asíncrona de permisos más antigua todavía se está ejecutando.