Descripción general de SCIM — Token SCIM, aprovisionamiento y autenticación
SCIM 2.0 (System for Cross-domain Identity Management) automatiza el aprovisionamiento de usuarios y grupos entre su proveedor de identidad y SecureCodingHub. Añada, actualice y elimine usuarios sin intervención manual, autenticando todo con un único token SCIM emitido desde la configuración de su organización.
¿Qué es SCIM?
SCIM sincroniza automáticamente los eventos del ciclo de vida de los usuarios desde su proveedor de identidad hacia SecureCodingHub: crea un usuario al contratarlo, actualiza atributos cuando cambian y lo desactiva al producirse la baja. Elimina por completo la gestión manual de usuarios.
Operaciones admitidas
El endpoint SCIM 2.0 de SecureCodingHub admite los siguientes recursos y operaciones:
| Recurso | Operaciones |
|---|---|
| Usuarios | Crear, Leer, Actualizar, Eliminar, Listar, Filtrar |
| Grupos | Crear, Leer, Actualizar, Eliminar, Listar |
| Service Provider Config | Leer (descubrimiento) |
| Esquemas | Leer (descubrimiento) |
| Tipos de recurso | Leer (descubrimiento) |
Autenticación
La API SCIM utiliza autenticación mediante token Bearer. Genere un token desde el panel de administración de SecureCodingHub y configúrelo en su proveedor de identidad.
| Ajuste | Valor |
|---|---|
| URL base | https://api.limeplate.com/api/sch/scim/v2 |
| Cabecera de autenticación | Authorization: Bearer {your-scim-token} |
Cómo funciona
Configurar el aprovisionamiento SCIM es un proceso sencillo de cuatro pasos:
El administrador genera un token SCIM en SecureCodingHub
El token se configura en el proveedor de identidad (Okta, Azure AD)
El IdP envía los cambios de usuarios/grupos al endpoint SCIM de SecureCodingHub
Los usuarios y equipos se crean, actualizan y eliminan automáticamente
Por qué SCIM es importante como evidencia de cumplimiento
SCIM no es solo una comodidad operativa. Para las organizaciones que operan bajo SOC 2, ISO 27001 o HIPAA, la desaprovisionamiento automatizado es el control que los auditores realmente comprueban. ISO 27001 Anexo A 9.2.6 exige la retirada de los derechos de acceso al finalizar el empleo, y los criterios comunes SOC 2 CC6.2 y CC6.3 esperan que el acceso lógico se revoque oportunamente cuando ya no sea necesario. Los procesos manuales de baja fallan en esta prueba con más frecuencia de la esperada, porque el rastro de evidencia depende de que se abra un ticket y de que una persona recuerde hacer clic en cada herramienta posterior.
Cuando SCIM está conectado a su proveedor de identidad, la baja se convierte en un único evento: RR. HH. marca al usuario como dado de baja en el HRIS, el IdP propaga la desactivación y SecureCodingHub establece al usuario como inactivo en el siguiente ciclo de aprovisionamiento. Los auditores obtienen un registro limpio de desactivaciones automatizadas correlacionadas con eventos del IdP, que es exactamente lo que quieren ver durante una ventana de observación de tipo II. Si está preparando una primera auditoría SOC 2, activar SCIM cuanto antes y dejar que genere seis meses de registros limpios es una de las victorias más baratas disponibles para generar evidencia.
Patrones de despliegue habituales
Tres patrones de despliegue cubren la mayoría de los entornos. Los despliegues greenfield son los más sencillos: no hay usuarios existentes en SecureCodingHub, SCIM se activa antes de enviar las primeras invitaciones y todo usuario tiene su origen en el IdP. Es el modelo más limpio y el que recomendamos siempre que sea viable. La sincronización parcial es el siguiente patrón: limita el alcance de SCIM a un único grupo o departamento, valida que los eventos de ciclo de vida se comportan correctamente y expande desde ahí. Resulta útil para organizaciones con miles de asientos donde un mapeo de atributos mal configurado podría afectar a muchas cuentas a la vez.
El tercer patrón es fusionar SCIM con usuarios manuales existentes. SecureCodingHub empareja los usuarios SCIM entrantes con cuentas existentes por la dirección de correo, de modo que la fusión suele ser no destructiva. El riesgo es que los usuarios creados manualmente con mayúsculas/minúsculas distintas, direcciones alias o valores de correo obsoletos generen duplicados. Antes de activar el interruptor, exporte la lista de usuarios actual, conciliela con el listado del IdP y resuelva cualquier discrepancia de direcciones en el IdP. Para más detalles sobre la configuración de proveedores, consulte las guías de Configuración de SCIM con Okta y Configuración de SCIM con Azure AD.