Just out of curiosity, has anyone ever attempted to use n8n as a SCIM facade?
I figured that with n8n having webhooks that we can set path variables, this could be a possibility to sit in front of a service with a REST API but without its own SCIM connector.
Describe the problem/error/question
Many services have REST API’s to create, retrieve, update, and delete users. However, these may not have a SCIM connector available, making it difficult to provision using an IdP like Okta or Entra.
Given that n8n has webhooks that allow for path variables, using a switch to pass these off to return ServiceProviderConfig, ResourceTypes, Schemas, and transforming responses to SCIM-formatted JSON might work.
Thoughts?
@ThomasLu_EarthDaily yeah é totalmente viável, as pessoas rodando n8n como um servidor SCIM fino assim, webhooks com :path params + um Switch é a forma certa e os endpoints estáticos (ServiceProviderConfig etc) são triviais. a parte difícil são três coisas: PATCH (IdPs enviam um array de operações PatchOp para tudo incluindo desativação como replace active=false, então você faz parse das operações não de um objeto limpo), filtering (Okta/Entra atingem ?filter=userName eq “x” para verificar existência antes de criar, então você faz parse do SCIM filter), e id vs externalId mapping (SCIM precisa de um id estável através das chamadas mas webhooks são stateless, então sua api downstream ou uma tabela de dados tem que ter dono dele). domine esses três mais status codes rigorosos e aguenta firme. qual é o serviço atrás disso?
Sim, funciona — construí uma fachada SCIM v2 leve com n8n. Aqui está o padrão:
**Configuração de Webhook**
Um nó Webhook por método HTTP (GET, POST, PUT, PATCH, DELETE) porque n8n não faz multiplex nativo de métodos no mesmo caminho. Configure cada um para o caminho base SCIM com uma variável de caminho: /scim/v2/Users/:id (id é opcional em GET-list e POST).
**Roteamento**
Um nó Switch em $json.method ou apenas confie em caminhos webhook separados. Para o parâmetro de filtro SCIM em GET /Users, analise $request.query.filter com um nó Code (a sintaxe de filtro é simples: userName eq “value” cobre 90% das consultas IdP).
**As partes difíceis**
Envelope de resposta — SCIM tem um esquema JSON rigoroso (array schemas, totalResults, Resources, meta.resourceType). O nó Respond to Webhook deve retornar essa forma exata ou Okta/Entra a rejeitará. Use um nó Code para construir o envelope antes da resposta.
PATCH usa JSON Patch (RFC 6902) ops, não uma mesclagem simples de corpo. Você precisa lidar com op: replace/add/remove explicitamente.
Cabeçalhos ETag / If-Match — alguns IdPs enviam estes para concorrência otimista. n8n não expõe nativamente cabeçalhos de resposta para requisições de entrada, então você tem que pular a validação de ETag ou analisar os cabeçalhos brutos de $request.
**O que funciona bem**
O provisionamento SCIM do Okta contra uma fachada n8n é alcançável em um fim de semana. Entra (Azure AD) é mais rigoroso no esquema de resposta, mas ainda é viável. O workflow n8n trata a camada de tradução de forma clara quando o envelope está certo.
Ficarei feliz em compartilhar o trecho de nó Code para o envelope de resposta SCIM se for útil.