SCIM 2.0: el estándar que automatiza el aprovisionamiento

La cuenta que ya tendría que estar ahí

Sara López empieza en Finanzas un lunes. El inicio de sesión único funciona: entra en el proveedor de identidad y el panel le muestra sus aplicaciones. Pulsa en la herramienta de gastos y le sale un error, “usuario no encontrado”. El login fue bien. El problema es que nadie creó su cuenta en esa herramienta, y el ticket para hacerlo sigue en la cola de alguien. Tres meses después, cuando David deja la empresa, pasa lo contrario: su cuenta en esa misma herramienta sigue activa varias semanas porque el script de baja falló sin avisar.

Los protocolos que hemos visto, SAML, OAuth y OIDC, responden preguntas en el momento en que el usuario inicia sesión: quién eres y si esta app puede actuar en tu nombre. Ninguno crea la cuenta. Antes de que Sara pueda entrar con SSO en una app SaaS, tiene que existir allí una cuenta suya con los atributos y grupos correctos, y cuando se vaya tiene que desaparecer. Eso es el aprovisionamiento, y SCIM 2.0 es el estándar que lo automatiza.

SCIM (System for Cross-domain Identity Management), definido en el RFC 7643 y el RFC 7644 y cerrado en 2015, es el protocolo que hay debajo del ciclo JML que estudiamos antes. Cuando alguien entra, SCIM crea sus cuentas; cuando cambia de puesto, las actualiza; cuando se va, las desactiva y luego las borra. SAML, OAuth y OIDC tratan de usar una identidad. SCIM trata de mantener las cuentas de esa identidad en todas las aplicaciones, por adelantado, para que cuando el usuario entre la cuenta ya esté ahí y sea correcta, y cuando se vaya ya no exista.

El problema que resuelve SCIM

Imagina una organización con un proveedor de identidad y cuarenta aplicaciones SaaS. Sin un estándar, conectarlas supone cuarenta integraciones, cada app con su API, sus nombres de campo y sus manías. Si tras una adquisición aparece un segundo proveedor de identidad, la cuenta se multiplica. Es un problema de N por M en el que cada fuente de identidad necesita un cableado a medida hacia cada aplicación, y el mantenimiento no se acaba nunca.

Muchas apps ofrecían solo ganchos propietarios o ninguna automatización, así que los equipos escribían scripts a medida: código pegamento que se rompía cada vez que la app cambiaba su API, que nadie entendía del todo y cuya mitad de bajas era la primera en saltarse o en fallar sin que nadie se enterara. Así sobrevivió la cuenta de David, y es justo el tipo de cuenta huérfana que la reconciliación tiene que salir a buscar.

SCIM sustituye ese enredo por un único contrato. Todas las apps que lo cumplen exponen los mismos esquemas, los mismos endpoints y las mismas operaciones, así que el proveedor de identidad habla un solo protocolo con todas. Conectas una app compatible con SCIM y el aprovisionamiento casi siempre funciona sin más.

flowchart LR
  accTitle: SCIM como puente de aprovisionamiento entre el IdP y las apps
  accDescr: El sistema de RR. HH. alimenta al proveedor de identidad, que actúa como cliente SCIM. El proveedor de identidad envía llamadas REST estándar de SCIM al endpoint SCIM de cada aplicación, que actúa como proveedor de servicio SCIM, para crear, actualizar y desactivar cuentas. Un solo protocolo estándar sustituye a un conector a medida por aplicación.
  HR[RR. HH. / fuente] --> IDP[IdP<br/>cliente SCIM]
  IDP -->|SCIM REST| A1[App A<br/>endpoint SCIM]
  IDP -->|SCIM REST| A2[App B<br/>endpoint SCIM]
  IDP -->|SCIM REST| A3[App C<br/>endpoint SCIM]

En el vocabulario de SCIM, el proveedor de identidad (Okta, Entra ID, etc.) es el cliente SCIM, y cada aplicación es un proveedor de servicio SCIM que expone un endpoint SCIM. El cliente empuja los cambios y el proveedor de servicio los aplica en su propio almacén de usuarios.

El modelo de recursos: User, Group, EnterpriseUser

SCIM estandariza la forma de los datos además de la API, mediante esquemas identificados por URN. Hay tres que importan. User es el recurso de la persona, con userName, name (dividido en givenName y familyName), emails, active, groups y más. Group es una colección con members, que sirve para dar acceso por grupos en la app de destino. EnterpriseUser es una extensión que añade los atributos laborales que le faltan a User: employeeNumber, department, manager, costCenter, division.

Cada recurso SCIM es JSON y se describe a sí mismo: enumera los schemas que cumple, para que el proveedor de servicio sepa cómo leer cada campo. Este es el recurso User que el proveedor de identidad habría enviado para Sara el primer día, con la extensión empresarial en un bloque con su propio espacio de nombres:

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User",
    "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
  ],
  "id": "2819c223-7f76-453a-919d-413861904646",
  "userName": "sara@example.com",
  "name": { "givenName": "Sara", "familyName": "López" },
  "emails": [{ "value": "sara@example.com", "primary": true }],
  "active": true,
  "groups": [{ "value": "finance", "display": "Finanzas" }],
  "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
    "employeeNumber": "EMP-08531",
    "department": "Finanzas",
    "manager": { "value": "26118915-6090-4610-87e4-49d8ca9f808d" }
  }
}

Hay dos campos en los que fijarse. El id es el identificador propio e inmutable que el proveedor de servicio asigna al recurso. No es el userName ni el identificador del proveedor de identidad, y es al que apuntan todas las operaciones posteriores. El booleano active es el interruptor de baja: ponerlo en false es como SCIM desactiva a un usuario sin borrarlo, que es exactamente la regla JML de desactivar primero.

Los endpoints

Un proveedor de servicio SCIM expone un conjunto pequeño y estándar de endpoints REST.

Los tres últimos, los de descubrimiento, importan más de lo que parece. Las implementaciones varían en lo que soportan, así que un cliente bien hecho los consulta para saber qué puede hacer de verdad cada proveedor de servicio, si admite PATCH u operaciones en bloque, por ejemplo, en lugar de darlo por hecho.

Las operaciones

SCIM traslada el ciclo de vida a verbos HTTP corrientes sobre esos endpoints.

En la práctica importan dos distinciones. La primera es PUT frente a PATCH. PUT sustituye el recurso entero, así que si te dejas un campo puedes vaciarlo, y el cliente tiene que mandar el objeto completo. PATCH aplica un cambio parcial, añadiendo, reemplazando o quitando atributos concretos, y es la opción más segura y ligera para los cambios rutinarios. La segunda es la búsqueda con filtros. SCIM define una sintaxis de filtros (userName eq "...", active eq true) para encontrar un recurso por sus atributos, y así es como el proveedor de identidad relaciona su usuario con el id del proveedor de servicio antes de actualizarlo.

SCIM moviendo el ciclo JML

Si juntas las operaciones, tienes el ciclo JML automatizado en forma de protocolo.

sequenceDiagram
  accTitle: Operaciones SCIM a lo largo del ciclo JML
  accDescr: Cuando una persona entra, el proveedor de identidad envía POST a /Users para crear la cuenta con active en true, y la app devuelve el id del recurso creado. Cuando la persona cambia de puesto, el proveedor de identidad envía PATCH para actualizar atributos y grupos. Cuando la persona se va, el proveedor de identidad envía primero PATCH para poner active en false y cortar el acceso, y más tarde DELETE para eliminar la cuenta tras el periodo de retención, siguiendo la regla de desactivar antes de borrar.
  participant IdP as IdP (cliente SCIM)
  participant App as App (proveedor de servicio)
  Note over IdP,App: Alta
  IdP->>App: POST /Users (active=true)
  App->>IdP: 201 Created (id)
  Note over IdP,App: Cambio de puesto
  IdP->>App: PATCH /Users/{id} (nuevo dpto + grupos)
  App->>IdP: 200 OK
  Note over IdP,App: Baja
  IdP->>App: PATCH /Users/{id} (active=false)
  App->>IdP: 200 OK
  IdP->>App: DELETE /Users/{id} (tras la retención)
  App->>IdP: 204 No Content

El protocolo recoge muy bien la disciplina del artículo de JML. La baja son dos pasos, no uno: PATCH active=false corta el acceso en el acto y el DELETE llega solo cuando termina la retención. Por eso SCIM importa para la seguridad y no solo por comodidad: convierte un desaprovisionamiento rápido y fiable en una capacidad estándar, en lugar de en el script que más se salta. Si la herramienta de gastos hubiera estado conectada por SCIM, la baja de David habría puesto active en false esa misma tarde.

Aprovisionamiento JIT frente a SCIM

Hay otra forma de crear cuentas que conviene comparar con SCIM: el aprovisionamiento justo a tiempo (JIT). Con JIT la cuenta se crea en el primer inicio de sesión. Cuando un usuario se autentica por primera vez con SAML u OIDC, la app lee la aserción o el ID token y crea ahí mismo una cuenta local con esos claims. No hace falta ninguna llamada previa.

JIT es sencillo y no necesita integración SCIM, pero solo crea cuentas, y solo al iniciar sesión. No las actualiza cuando cambian los atributos y nunca las borra. Un usuario creado por JIT que se va simplemente deja de entrar, y la cuenta se queda ahí dormida. JIT no tiene ninguna respuesta para las bajas. SCIM aprovisiona antes del login y se encarga también de los cambios y las bajas: todo el ciclo, no solo el primer momento.

Así que usa SCIM siempre que necesites gestionar de verdad el ciclo de vida, que es la mayoría de los casos de empleados, y deja JIT como una comodidad ligera para casos en los que solo hace falta crear, o como complemento de SCIM. Si una app solo admite JIT, has heredado justo el problema de cuentas huérfanas que SCIM existe para resolver. Es un intercambio razonable para una herramienta interna de usar y tirar, y uno peligroso en silencio para cualquier cosa que guarde datos sensibles o pase auditorías.

Por qué SCIM gana a los scripts a medida

Las razones son concretas. Aprendes un modelo de integración en lugar de cuarenta, y conectar una app SaaS nueva pasa a ser configuración en vez de un proyecto de desarrollo. Las bajas se vuelven fiables, porque active=false y DELETE son operaciones estándar y no el final frágil de un script, y eso reduce directamente las cuentas huérfanas. Los conectores los mantiene el ecosistema: los grandes proveedores de identidad (Okta, Entra ID, OneLogin) y miles de apps SaaS traen soporte SCIM, así que no tienes que mantener tu propio pegamento. Y es REST y JSON sobre HTTPS, fácil de probar, registrar y razonar, a diferencia de las sincronizaciones propietarias opacas.

Eso sí, la frase “soporta SCIM” esconde trampa. Hay proveedores de servicio que implementan POST y PUT pero no PATCH, otros que solo aceptan una parte de la sintaxis de filtros y otros que tratan el DELETE como una desactivación suave. Lee el /ServiceProviderConfig del destino y prueba en concreto el camino de las bajas. La distancia entre “compatible con SCIM” en una ficha comercial y “desactiva usuarios de forma fiable” en producción es donde se esconden los fallos reales de offboarding.

SCIM a escala: sincronización inicial, paginación y operaciones en bloque

Conectar SCIM a una app que ya tiene decenas de miles de usuarios saca a la luz problemas que el caso sencillo no muestra.

La primera ejecución tiene que emparejar las cuentas que ya existen en la app con las identidades del proveedor de identidad, normalmente con un filtro como userName eq "...", antes de poder gestionarlas. Si el emparejamiento sale mal, creas cuentas duplicadas en lugar de adoptar las existentes. GET /Users devuelve los resultados por páginas (startIndex, count, totalResults), y el cliente tiene que recorrerlas en vez de suponer que una respuesta los trae a todos. El endpoint /Bulk permite enviar muchas operaciones en una sola petición y ahorra viajes en los cambios masivos, aunque el soporte, como siempre, es desigual. Y los proveedores de servicio limitan la tasa de peticiones, así que un cliente bien hecho espera y reintenta en lugar de machacar el endpoint durante una sincronización grande.

El protocolo en sí es simple. Estos detalles operativos son los que deciden si una implantación de SCIM sale adelante o se atasca, y donde se va la mayor parte del trabajo de ingeniería.

Proteger el endpoint SCIM

Un endpoint SCIM es una de las interfaces más potentes que expone una aplicación: puede crear, cambiar y borrar a cualquier usuario. Eso lo convierte en un objetivo valioso y en una responsabilidad seria.

Las llamadas SCIM van autenticadas, casi siempre con un bearer token de OAuth 2.0 emitido para el conector del proveedor de identidad. Ese token es, en la práctica, una credencial de administrador de todo el almacén de usuarios, así que trátalo como tal. Guárdalo en un gestor de secretos, rótalo, limita su alcance todo lo que permita el proveedor y vigila su uso. Un token SCIM filtrado permite a un atacante crear cuentas puerta trasera o borrar usuarios en masa. El proveedor de servicio debe autorizar al cliente con rigor, validar las entradas y registrar cada operación, porque las acciones de aprovisionamiento son justo lo que un auditor o un equipo de respuesta a incidentes necesitará reconstruir. Y siempre TLS: ni los datos de usuario ni el token deben cruzar nunca un canal en claro.

Hay una ironía que conviene recordar. El protocolo pensado para retirar accesos de forma fiable es, él mismo, una vía de acceso muy potente. Proteger el canal SCIM es parte de proteger la identidad, no algo para más adelante.

Lo que SCIM no hace

SCIM hace muy bien aquello para lo que existe, y sus bordes importan, porque marcan dónde empiezan otras capas.

No gestiona permisos granulares. SCIM aprovisiona cuentas y membresías de grupo, no permisos finos dentro de una app. Puede meter a Sara en el grupo Finanzas; no puede decir “puede aprobar reembolsos de hasta 5.000 $” ni “solo lectura sobre los datos de la UE”. Esos derechos de acceso viven dentro de cada aplicación o en una capa de gobierno o de autorización. Tampoco evalúa roles dinámicos o basados en políticas. SCIM empuja valores concretos de atributos y grupos; no evalúa reglas como “da este rol a cualquiera de Finanzas en Alemania”. Esa lógica le toca al proveedor de identidad o a la plataforma de IGA al decidir qué enviar, o a un motor de políticas en el momento del acceso. Su modelo es grueso a propósito y cubre el mínimo común de usuarios y grupos, que es lo que lo hace interoperable y también la razón por la que las estructuras profundas y propias de cada app no encajan bien. Y las diferencias entre fabricantes en PATCH y en los filtros hacen que, en la práctica, SCIM sea una familia de dialectos más que un comportamiento único.

Ese límite está detrás de un malentendido frecuente. Los equipos esperan que SCIM “sincronice permisos” y se sorprenden al ver que solo sincroniza cuentas y nombres de grupo. El grupo es un asa gruesa, y es la app de destino la que decide qué significa Finanzas por dentro. Cuando alguien pide que SCIM transporte permisos ricos, lo correcto es llevar esa necesidad a las capas de gobierno y autorización en lugar de retorcer el protocolo de aprovisionamiento.

Nada de esto es un defecto; es alcance. SCIM se encarga del ciclo de vida de la cuenta. La autorización fina es otro problema, que resuelven la IGA y los modelos de autorización que veremos más adelante en este dominio: RBAC, ABAC, ReBAC y los motores de políticas.

Cómo encaja SCIM con los demás protocolos

SCIM convive con los protocolos de federación como complemento, no como alternativa. SCIM trabaja por adelantado y mantiene la cuenta existente y correcta: crea la cuenta de Sara en la app, pone sus atributos, la mete en los grupos adecuados y la retira cuando se va. SAML u OIDC trabajan al iniciar sesión y demuestran que es Sara de verdad: se autentica en el proveedor de identidad y entra en una app donde ya tiene cuenta.

Una implantación empresarial típica conecta los dos a la misma app desde el mismo proveedor de identidad: SCIM para el ciclo de vida y SAML u OIDC para la autenticación. Quita SCIM y tienes inicio de sesión único hacia cuentas que nadie mantiene, incluidas las de gente que se fue y que puede seguir autenticándose si otra pieza falla. Quita el SSO y tienes cuentas bien cuidadas sin una forma limpia de entrar. SCIM administra la cuenta; la federación autentica a la persona.

Eso también ordena el recorrido de esta parte del módulo: el directorio, donde vive la identidad; SAML, OAuth y OIDC, cómo viaja al iniciar sesión; y SCIM, cómo se mantienen las cuentas a lo largo del tiempo.

Resumen

SCIM 2.0 es el estándar que automatiza el ciclo de vida de las cuentas.

1. Es un estándar de aprovisionamiento REST y JSON (RFC 7643 y 7644) entre un proveedor de identidad, el cliente SCIM, y las apps, los proveedores de servicio.
2. Tiene tres esquemas: User, Group y la extensión EnterpriseUser (department, manager, employeeNumber).
3. Define endpoints estándar (/Users, /Groups, /Bulk, /Schemas, /ServiceProviderConfig) y operaciones estándar que llevan el alta, la lectura, el cambio, la baja, la búsqueda y PATCH a verbos HTTP.
4. Es JML en forma de protocolo: POST para las altas, PATCH para los cambios de puesto, active=false y después DELETE para las bajas.
5. Sustituye a los scripts a medida y a los ganchos propietarios, convierte las bajas fiables en una capacidad estándar y reduce las cuentas huérfanas. El aprovisionamiento JIT crea cuentas pero nunca las retira.
6. Sus límites marcan dónde empiezan las capas siguientes: SCIM maneja cuentas y grupos, no permisos granulares ni roles dinámicos. En la práctica va de la mano de SAML u OIDC contra la misma app.

Ejercicios prácticos

Están pensados para hacerse, no solo para leerse.

1. Lee un ServiceProviderConfig real. Busca la documentación SCIM de una app que lo soporte (Okta, Slack, GitHub y muchas otras publican sus esquemas) y averigua qué operaciones admite. ¿Hace PATCH? ¿Operaciones en bloque? ¿Qué operadores de filtro?
2. Modela un usuario. Escribe el JSON de un recurso User de SCIM para una incorporación en Finanzas, con la extensión EnterpriseUser con departamento y responsable. Marca qué campo asigna el proveedor de servicio y no tú.
3. Guioniza el ciclo. Para un alta, un cambio de puesto a Ventas y una baja, escribe el verbo HTTP, el endpoint y el contenido clave de cada llamada SCIM, y explica por qué la baja son dos operaciones.
4. PUT frente a PATCH. Solo tienes que cambiar el departamento de un usuario. Escribe la petición PATCH y explica qué podría salir mal si usaras PUT con un cuerpo parcial.
5. Encuentra el límite. Tu app necesita otorgar “aprobador, hasta 10.000 $, solo región UE”. Explica por qué SCIM no puede expresarlo, qué sí puede aportar (la parte de cuenta y grupo) y qué capa tiene que encargarse del resto.
6. ¿JIT o SCIM? Elige uno para cada caso y justifícalo: una app de empleados en la que quien se va debe perder el acceso en menos de una hora, y una wiki interna de bajo riesgo donde las cuentas pueden crearse en el primer login y nunca necesitan cambios. Después di qué perderías eligiendo el otro.

Tres preguntas para ponerte a prueba

1. Una empresa conecta su proveedor de identidad a una app SaaS nueva que anuncia “soporte SCIM”, y aun así la gente que se va conserva el acceso. Da tres razones concretas por las que puede pasar pese a SCIM y cómo diagnosticarías cada una.
2. Explica cómo expresa SCIM, a nivel de protocolo, la regla JML de desactivar primero y borrar después, y por qué esos dos pasos importan tanto para la seguridad como para la auditoría.
3. ¿Por qué SCIM no puede, a propósito, modelar permisos granulares, y qué te dice eso sobre dónde tiene que vivir de verdad la lógica de autorización?