Si tu empresa usa Google Workspace como directorio de identidades y AWS como plataforma cloud, tarde o temprano aparece el mismo problema: los usuarios entran con SSO, pero los grupos no se sincronizan solos entre Google y AWS IAM Identity Center. Eso obliga a crear grupos a mano, asignar permisos uno por uno y correr riesgo de desalineación cada vez que alguien entra o sale del equipo.

El proyecto open source idp-scim-sync resuelve ese hueco: sincroniza usuarios y grupos desde Google Workspace hacia AWS IAM Identity Center (antes AWS SSO) usando SCIM y las APIs de ambos lados. En este artículo explicamos cuándo conviene, cómo funciona y qué tener en cuenta antes de implementarlo en producción.

El contexto: SSO sin aprovisionamiento completo

AWS IAM Identity Center permite federar identidades con proveedores externos mediante SAML y aprovisionar usuarios con SCIM 2.0. Google Workspace es un IdP muy usado en empresas argentinas y latinoamericanas, pero la integración nativa tiene limitaciones importantes:

• El aprovisionamiento SCIM automático de Google hacia IAM Identity Center cubre principalmente usuarios, no grupos de forma completa.
• Sin sincronización de grupos, las asignaciones de cuentas AWS, permission sets y aplicaciones se vuelven difíciles de mantener.
• Cada cambio en Google (alta, baja, cambio de equipo) puede quedar reflejado tarde o nunca en AWS.

El resultado práctico: el login funciona, pero el gobierno de identidades en la nube queda frágil. Para equipos que crecen, rotan personal o segregan accesos por área (desarrollo, finanzas, operaciones), eso no escala.

¿Qué es SCIM y por qué importa?

SCIM (System for Cross-domain Identity Management) es un estándar para automatizar el ciclo de vida de identidades entre un proveedor de identidad (IdP) y aplicaciones o servicios. En lugar de crear usuarios manualmente en cada sistema, el IdP (o un conector) envía altas, bajas y cambios de atributos de forma automática.

En AWS, el endpoint SCIM de IAM Identity Center recibe esos datos y los refleja en el Identity Store. Desde ahí podés asignar usuarios y grupos a cuentas de la organización, permission sets y aplicaciones SAML.

SCIM no reemplaza SAML: SAML resuelve el login (autenticación); SCIM resuelve el aprovisionamiento (quién existe, en qué grupos está). Necesitás ambos para una experiencia integrada y segura.

¿Qué es idp-scim-sync?

idp-scim-sync es una herramienta open source (licencia Apache 2.0) que mantiene sincronizados los grupos y usuarios de Google Workspace con IAM Identity Center. Está pensada para ejecutarse como:

• Función AWS Lambda disparada por EventBridge (por defecto cada 15 minutos).
• Contenedor en ECS, Kubernetes o entorno on-premise.
• CLI local (idpscim) para pruebas o ejecuciones manuales.

Incluye además idpscimcli, una utilidad para inspeccionar datos en Google Workspace y en el SCIM de AWS mientras validás la configuración.

Flujo de sincronización

1. La Lambda (o el proceso CLI) lee grupos y miembros desde la API de Google Workspace.
2. Compara el estado actual con un archivo de estado en S3 (implementación propia para reducir llamadas a la API SCIM de AWS).
3. Aplica altas, bajas y cambios en IAM Identity Center vía API SCIM.
4. Actualiza el state file en S3 para la próxima ejecución.

Ese state file es clave: evita reprocesar todo en cada ciclo y mitiga limitaciones del API SCIM de AWS respecto a consultas y reconciliación.

idp-scim-sync vs. otras opciones

Antes de implementar, conviene ubicar la herramienta en el panorama:

SCIM nativo Google → IAM Identity Center — Adecuado si solo necesitás usuarios y podés gestionar grupos manualmente o con poca frecuencia de cambios. Es la opción más simple si tu organización es chica.

ssosync (AWS Labs) — Proyecto anterior de referencia para sincronizar Google Workspace con AWS SSO. idp-scim-sync nació como evolución/reescritura con enfoque en grupos, state en S3 y despliegue serverless más claro. Si evaluás alternativas, compará mantenimiento activo, soporte de grupos y modelo de despliegue.

idp-scim-sync — Recomendable cuando:

• Usás Google Workspace + AWS con varias cuentas en AWS Organizations.
• Los permission sets se asignan por grupo (ej. aws-admins, aws-developers, aws-readonly).
• Querés automatización periódica sin intervención manual.
• Buscás ejectuar la sync en Lambda dentro de tu propia cuenta AWS (control, auditoría, costo bajo).

En Nodo Norte IT trabajamos con AWS, Azure, GCP y Huawei Cloud; un proyecto puede estar 100% en AWS sin implicar arquitectura híbrida. Este tipo de integración encaja en despliegues donde IAM Identity Center es el centro de acceso a la organización.

Requisitos previos

Para un despliegue típico en AWS necesitás:

• Google Workspace con API de Admin habilitada y una service account con domain-wide delegation.
• AWS IAM Identity Center habilitado en la organización, con SCIM configurado (endpoint + bearer token).
• Grupos en Google Workspace que representen los roles o equipos que querés reflejar en AWS.
• Una cuenta AWS para hospedar la Lambda, el bucket S3 del state file, EventBridge y los roles IAM mínimos necesarios.

La documentación del proyecto detalla los permisos IAM, el formato del state file y las variables de entorno. Revisá siempre la versión actual en GitHub antes de producción.

Aspectos de configuración importantes

Sincronización por grupos

idp-scim-sync implementa el método --sync-method groups: parte de los grupos de Google Workspace y sincroniza sus miembros hacia AWS. Podés filtrar qué grupos entran en el scope (no es necesario sincronizar todo el directorio).

Atributos de usuario

Por defecto sincroniza atributos opcionales del usuario (teléfonos, direcciones, datos enterprise, etc.). Podés acotar qué campos enviar con sync_user_fields para alinearlos con lo que IAM Identity Center acepta y con tu política de datos.

Frecuencia y ventana de cambios

El intervalo por defecto (15 minutos) es un buen equilibrio entre frescura y carga sobre APIs. En entornos con cambios muy frecuentes, evaluá si necesitás menor latencia; en entornos estables, podés ampliar el intervalo.

Token SCIM y rotación

El bearer token de SCIM en IAM Identity Center expira. AWS notifica antes del vencimiento, pero conviene documentar el proceso de rotación: generar token nuevo, actualizar la configuración de la Lambda y validar que la sync sigue funcionando. Si el token vence, el aprovisionamiento automático se detiene (los usuarios existentes no pierden acceso de inmediato, pero los cambios dejan de aplicarse).

Seguridad y buenas prácticas

• Principio de menor privilegio en los roles IAM de la Lambda y en la service account de Google.
• Bucket S3 del state file con cifrado, bloqueo de acceso público y políticas restrictivas.
• Logs en CloudWatch para auditar cada ejecución; alertas si la sync falla varias veces seguidas.
• Probar en un entorno de staging con un subconjunto de grupos antes de sincronizar todo el directorio.
• Usar idpscimcli para validar datos en ambos lados sin modificar producción.
• Definir un externalId estable en el mapeo SCIM para que cambios de email o nombre no rompan la identidad en AWS.

La sincronización de identidades es parte del perímetro de seguridad cloud. Conviene alinearla con políticas de offboarding: cuando alguien se da de baja en Google, el grupo y el usuario deben reflejarse en AWS en el próximo ciclo (o antes, si ejecutás una sync manual).

Limitaciones a tener en cuenta

Ninguna herramienta es mágica. Según la documentación actual del proyecto:

• El foco principal es la sincronización por grupos, con filtrado de grupos (no de usuarios individuales como entrada principal).
• Depende de las APIs de Google Workspace y del SCIM de IAM Identity Center; cambios en esos servicios pueden requerir actualizar la herramienta.
• Es un proyecto comunitario/open source: evaluá soporte interno o de un partner para producción crítica.

Si tu IdP no es Google Workspace (por ejemplo Entra ID / Azure AD), el concepto SCIM sigue siendo válido en AWS y Azure, pero idp-scim-sync está orientado al par Google + AWS.

Casos de uso típicos en empresas

Equipo de desarrollo con varias cuentas AWS

Grupos como gcp-dev o aws-prod-readonly en Google se reflejan en IAM Identity Center; los permission sets se asignan al grupo, no usuario por usuario.

Consultoras y equipos que rotan

Alta y baja de consultores en Google Workspace se propaga a AWS sin tickets manuales al área de infraestructura.

Compliance y auditoría

Un solo origen de verdad (Google Workspace) alimenta el Identity Store; las auditorías de “quién tenía acceso a qué” se simplifican si el proceso está documentado y logueado.

¿Necesitás ayuda para implementarlo?

Desplegar idp-scim-sync implica tocar IAM Identity Center, Lambda, S3, Google Workspace Admin y políticas de seguridad. No es solo “subir un script”: hay que diseñar qué grupos sincronizar, cómo mapear permission sets y cómo operar la rotación de tokens.

En Nodo Norte IT acompañamos empresas en implementación y operación de identidad y accesos en la nube. Si estás armando tu landing zone en AWS o consolidando SSO con Google Workspace, podemos ayudarte a evaluar si idp-scim-sync encaja o si conviene otra estrategia de aprovisionamiento.

También podés empezar con una POC en la nube para validar arquitectura de identidad antes de escalar a toda la organización.

Conclusión

idp-scim-sync cubre un vacío real: mantener grupos y usuarios de Google Workspace alineados con AWS IAM Identity Center cuando el SCIM nativo no alcanza. Es una solución serverless, repetible y bien documentada para equipos que ya viven en el ecosistema Google + AWS.

Antes de producción, definí el alcance de grupos, probá con idpscimcli, automatizá alertas y documentá la rotación del token SCIM. Con eso, la sincronización de identidades deja de ser un cuello de botella y pasa a ser parte de tu transición ordenada a la nube.