November 5, 2026
|
5 min read
Provisionamento SCIM: Por que o desprovisionamento é a parte que todos fazem errado
Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
O que é o SCIM na prática
SCIM significa System for Cross-domain Identity Management (Sistema de Gerenciamento de Identidade entre Domínios). É um padrão aberto — esquema no RFC 7643, protocolo no RFC 7644 — que define uma API REST para mover dados de identidade entre sistemas. A versão 2.0 é a que todos os principais IdPs implementam.
O modelo mental é mais simples do que a sigla. Seu IdP é o cliente, o aplicativo downstream é o servidor. O IdP mantém uma lista de pessoas e grupos e, quando essa lista muda, ele faz uma chamada HTTP para comunicar a alteração.
O SCIM define duas coleções de recursos, e todo o protocolo gira em torno delas:
E o ciclo de vida é mapeado para verbos HTTP comuns:
A penúltima linha é a mais importante. O SCIM possui uma forma padrão e de primeira classe para dizer esta pessoa não deve mais ter acesso — e esse sinal se origina onde a saída de alguém já está registrada, ou seja, na identidade alimentada pelo RH, e não em uma planilha controlada pela TI.
SCIM não é SSO, e a diferença é importante
O SSO responde a uma pergunta no momento do login: esta pessoa é quem ela diz ser, agora mesmo? Uma asserção SAML ou um token OIDC chega, o aplicativo valida e a sessão é iniciada.
O SCIM responde a uma pergunta continuamente: esta pessoa deveria existir aqui? Ele é executado em seu próprio cronograma, independentemente de alguém estar fazendo login ou não.
A lacuna entre esses dois é o problema central. Se você usar SSO apenas com criação de conta just-in-time, seu IdP protege a porta da frente enquanto as contas atrás dela se acumulam para sempre. Desativar alguém no IdP bloqueia novos logins, mas o objeto da conta continua lá, ainda vinculado a funções, associações e — o que é crítico em uma plataforma de IA — quaisquer chaves de API e tokens de serviço que tenham sido coletados.
Por que o desprovisionamento é a parte que todos erram
O onboarding é uma falha barulhenta. O offboarding é uma falha silenciosa. Essa assimetria explica quase todas as descobertas de revisão de acesso que já vimos.
Ninguém reclama de ter um acesso que não deveria ter. Quando o provisionamento falha, um novo engenheiro avisa em um canal em menos de vinte minutos. Quando o desprovisionamento falha, o beneficiário já foi embora. Não existe um ciclo de feedback, então o problema persiste até que um auditor vá atrás dele.
Checklists manuais de desligamento ficam obsoletos. O checklist é criado quando a empresa tem oito ferramentas SaaS. Dois anos depois, ela tem sessenta, e o checklist continua com oito.
O tempo de permanência é longo. Como nada traz o problema à tona, contas órfãs geralmente são medidas em meses e aparecem durante uma auditoria ou um incidente — os dois piores momentos para encontrá-las.
Em plataformas de IA, uma conta órfã é mais do que apenas um login. Um registro de usuário inativo pode estar vinculado a credenciais de provedores de modelos, acesso a servidores MCP, cargas de trabalho implantadas e chaves de API de longa duração. Sessões de navegador expiram por conta própria. Credenciais programáticas, não. É por isso que autenticação de API e RBAC em um gateway de IA precisam ser baseados em identidade, e não em chaves — uma chave sem dono é uma chave que ninguém jamais revogará.
O SCIM elimina a etapa humana. O desligamento é registrado uma única vez, no IdP, e se propaga para fora.
SCIM vs JIT vs apenas convite: qual modo de provisionamento usar
O TrueFoundry suporta três modos de provisionamento, e um tenant usa exatamente um por vez. Esta é a decisão que a maioria das equipes está realmente tentando tomar quando busca por SCIM.
Três conclusões surgem desta tabela.
JIT não é um SCIM simplificado. Ele é metade do SCIM — a metade visível. Ele lida bem e sem configuração com uma nova pessoa que precisa de uma conta. Ele não faz nada em relação a alguém que sai. Se o seu motivo para escolher o JIT é "vamos lidar com o desligamento manualmente", escreva honestamente quem é o responsável por essa etapa e como ela é auditada.
A opção "apenas convite" não é pior, é apenas diferente. Para um prestador de serviços de uma empresa parceira sem registro no seu IdP, um convite é o mecanismo correto. O problema é usá-lo para funcionários que já estão no seu IdP, porque, nesse caso, seus administradores se tornam uma réplica manual de um sistema pelo qual você já paga.
A sincronização de grupos é a linha que as pessoas subestimam. Criar usuários automaticamente economiza alguns minutos por contratação. Sincronizar grupos é o que mantém a autorização correta ao longo do tempo — um custo permanente, e não algo que se faz uma única vez.
Onde as equipes erram
Tratar SSO como desprovisionamento. O erro mais comum, e compreensível, é que desativar um usuário no IdP bloqueia novos logins. O que isso não faz é remover a conta, suas associações de grupo ou quaisquer credenciais que ela possua. Bloquear a porta da frente não é o mesmo que encerrar a conta.
Nomes de grupos que falham silenciosamente na sincronização. Todo sistema de provisionamento tem restrições de nomenclatura, e os grupos do IdP geralmente são nomeados por pessoas que nunca as leram. Um grupo chamado ML Platform — Prod (EMEA) contém um espaço, um travessão e parênteses, e não se tornará uma equipe válida no sistema de destino. A falha é silenciosa: os usuários sincronizam, o grupo não, e ninguém percebe até que alguém pergunte por que a equipe está vazia.
Presumir que o SCIM alcança todas as permissões que uma pessoa possui. O SCIM sincroniza usuários e associações de grupo. Ele não sabe nada sobre permissões concedidas diretamente, fora de qualquer grupo, em um recurso específico. Remova alguém de uma equipe e a concessão direta permanece. Esta é a resposta mais comum para “por que essa pessoa ainda consegue ver isso”.
Armazenar o token SCIM de forma inadequada, ou nem armazená-lo. O token Bearer é exibido apenas uma vez. As equipes colam no IdP, fecham a aba e não guardam nenhuma cópia. Isso é contornável — você pode gerar um novo —, mas fazer isso invalida o antigo, então o provisionamento para até que o IdP também seja atualizado. Coloque-o no seu gerenciador de segredos antes de fechar a aba.
Como o provisionamento SCIM funciona no TrueFoundry
O TrueFoundry oferece suporte a SCIM tanto para configurações de SSO OIDC quanto SAML v2. Antes de configurar o provisionamento, você precisa que o SSO esteja funcionando — a URL e o token SCIM ficam junto com a configuração de SSO, não em uma integração separada.
Passo 1 — Configurar SSO
Vá para Plataforma → Configurações → SSO, ative Habilitado, escolha seu provedor e selecione OIDCouSAML v2.
Para OIDC, você fornece um ID do Cliente, um Segredo do Cliente e uma URL do Emissor; a URL de retorno no lado do IdP é sempre https://login.truefoundry.com/oauth2/callback. Para SAML, você fornece a URL de SSO do IdP e um certificado de assinatura X.509, e então retorna após salvar para coletar a URL de retornoeEmissor TrueFoundry gera e cole esses dados em seu IdP.
Um detalhe que economiza tempo mais tarde: configure seu IdP para emitir declarações chamadas email, sub e groups. Esses são os padrões do TrueFoundry, e criar aliases para os atributos no lado do IdP significa que você nunca precisará tocar nos campos avançados.
Passo 2 — Ativar o SCIM
Vá para Configurações → Segurança e Acesso → Provisionamento e selecione SCIM. É aqui que residem todos os três modos de provisionamento, e escolher um deles é como você define o modelo de ciclo de vida do tenant.
Passo 3 — Copiar a URL base do SCIM
Expanda sua configuração de SSO salva para revelar a URL do SCIM junto com o restante dos metadados. Este é o valor que seu IdP chama.
Passo 4 — Gerar o token SCIM
Clique no ícone de chave ao lado da configuração de SSO para gerar o token de autenticação SCIM.
Trate-o como uma senha. Ele é exibido apenas no momento da criação; se você perdê-lo, deverá gerar um novo e o token anterior deixará de funcionar.
Passo 5 — Aponte seu IdP para ele
Nas configurações de provisionamento do seu IdP, defina a URL Base (alguns IdPs a chamam de URL do Locatário/Tenant) para a URL SCIM, defina Autenticação como Token de Portador (Bearer Token) e cole o token SCIM como o valor do token. Em seguida, atribua usuários e grupos no IdP e inicie o provisionamento. Em poucos minutos, os usuários e equipes aparecerão no TrueFoundry.
Grupos do IdP tornam-se equipes — esta é a parte que importa
A maioria dos guias de SCIM para por aí, na sincronização de usuários. A sincronização de usuários é a parte fácil. O motivo para usar SCIM em uma plataforma como esta é a sincronização de grupos, porque é nos grupos que a autorização reside.
Quando o locatário está configurado para SCIM, cada grupo que seu IdP envia torna-se automaticamente uma equipe no TrueFoundry. Adicione alguém ao grupo do IdP e essa pessoa entrará na equipe; remova-a e ela sairá.
Equipes sincronizadas são equipes comuns em todos os outros aspectos. Você pode conceder a elas acesso a recursos, atribuir funções em nível de locatário e adicionar mapeamentos de declarações (claims) do provedor de identidade.
Seja preciso quanto à divisão de tarefas, pois é fácil reivindicar permissões em excesso. O SCIM não decide o que uma equipe pode fazer — um administrador concede as funções à equipe uma única vez, de forma deliberada. O SCIM automatiza a associação, e como as permissões são vinculadas à equipe, a associação atual significa um conjunto de permissões efetivas atual. Projete a autorização uma vez; deixe que o IdP lide com as mudanças.
Existe uma restrição de nomenclatura a ser respeitada. O nome do grupo no IdP torna-se o nome da equipe, portanto, pode conter apenas caracteres alfanuméricos, hifens e sublinhados, e pode ter no máximo 36 caracteres. Renomeie os grupos no IdP antes de ativar o provisionamento, não depois.
Um exemplo prático: um prestador de serviços na equipe da plataforma de ML
Aqui está o ciclo de vida completo, com as etapas manuais destacadas.
Configuração única (manual). Um administrador cria um grupo no IdP chamado ml-platform-contractors — letras minúsculas, hifens, 23 caracteres, seguro. O SCIM faz o push e uma equipe com o mesmo nome aparece no TrueFoundry. O administrador concede a essa equipe o que ela precisa: a conta do provedor de modelo relevante, acesso de Usuário em dois servidores MCP, nada mais. Essa é a estrutura de autorização, feita uma única vez.
Integração (automática). Um prestador de serviços começa. O provisionamento de RH os adiciona ao ml-platform-contractors. O SCIM cria o usuário deles no TrueFoundry e os adiciona à equipe. Eles fazem login via SSO com exatamente o acesso que a equipe possui. Ninguém precisou abrir um chamado.
Mudança de escopo (automática). Três meses depois, o prestador de serviços muda para um projeto diferente. Alguém os remove do ml-platform-contractors e os adiciona a outro grupo. O SCIM ajusta ambas as equipes. O acesso deles ao provedor de modelo desaparece com a associação à equipe, e nenhum administrador precisou tocar no TrueFoundry.
Desligamento (automático). O contrato termina. O registro no IdP é desativado. O SCIM marca o usuário do TrueFoundry como inativo, e um usuário desativado é rejeitado durante o fluxo de autenticação. A conta deixa de funcionar, sem que ninguém precise se lembrar de que o TrueFoundry estava na lista.
A única coisa que ainda é manual. Se esse prestador de serviços também tiver recebido algo diretamente — digamos, um grupo secreto fora de qualquer equipe —, essa concessão permanece, pois nunca veio do IdP. A desativação bloqueia o login de qualquer forma, mas o registro da concessão permanece até que alguém o remova. Inclua isso na sua revisão de acesso. É o mesmo padrão que aparece em todo o controle de acesso MCP corporativo: permissões herdadas e diretas se combinam, e remover uma não remove a outra.
Pontos de atenção importantes
Para o Entra ID e o Okta, o SCIM exige SAML. A matriz de capacidades lista o SSO apenas como recomendado para o SCIM em geral, mas para os dois IdPs mais utilizados, os guias de provisionamento dependem da configuração SAML. Se você configurar o OIDC com o Entra ou o Okta e depois procurar pelo SCIM, terá que reconfigurar tudo.
Um modo de provisionamento por tenant. Você não pode executar o SCIM para funcionários e convites apenas para prestadores de serviços no mesmo tenant ativando ambos os recursos. Se precisar incluir alguém que não está no seu IdP, o fluxo de Convidar Usuário em Acesso > Usuários ainda existe — e, ao usá-lo para um usuário de SSO, deixe a caixa de seleção Enviar e-mail para definir senha desmarcada, já que não há senha a ser definida.
Desativação e exclusão são operações diferentes. A desativação bloqueia o login e é o que o SCIM gerencia. Excluir um usuário permanentemente é uma ação administrativa separada, e o TrueFoundry a impede até que o usuário tenha sido explicitamente removido de todos os recursos e equipes. Essa proteção evita que você exclua uma identidade enquanto concessões pendentes ainda fazem referência a ela.
A página dedicada de Provisionamento chegou na v0.143. Em versões anteriores, o SCIM é configurado diretamente no formulário de SSO. Os valores são os mesmos; as telas são diferentes.
Leituras relacionadas
- Autenticação de API e RBAC em um Gateway de IA — como a identidade é transmitida para as solicitações do gateway
- Controle de Acesso MCP: Protegendo Agentes de IA com um Gateway MCP — o que as equipes criadas pelo SCIM realmente recebem permissão para acessar
- Controle de acesso MCP corporativo — concessões diretas versus herdadas em escala organizacional
- Estrutura de Governança de IA — onde o provisionamento se encaixa no conjunto mais amplo de controles
- Segurança MCP — o modelo de ameaças por trás de uma higiene de identidade rigorosa
Conclusão
O provisionamento SCIM geralmente é vendido com base na história do onboarding, porque demonstrações de onboarding são atraentes. O retorno real está na outra ponta. O desprovisionamento é o modo de falha que não possui ciclo de feedback — sem chamado, sem reclamação, sem alerta — e a única solução duradoura é fazer com que o desligamento seja propagado automaticamente a partir do único sistema que já tem essa informação.
No TrueFoundry, isso se resume a três configurações e uma decisão de design: ative o SCIM, copie a URL base, gere o token e decida de uma vez o que a equipe de cada grupo tem permissão para fazer. Depois disso, o organograma mantém seu modelo de acesso para você, e as contas que não deveriam existir deixam de existir por conta própria — o único processo de offboarding que sobrevive ao crescimento de uma empresa.
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
Built for Speed: ~10ms Latency, Even Under Load
Try now.
Start free
How Can You Prevent GenAI Costs From Spiraling at Scale?
Gartner Hype Cycle for Platform Engineering 2026
One Layer of Control for All AI
Discover More
No items found.
.png)
No items found.
Recent Blogs
.webp)
.webp)
.png)
.png)
.png)
.png)
.png)
.webp)
.webp)
.png)
.png)
.png)
Frequently asked questions
O que é provisionamento SCIM?
O provisionamento SCIM é a sincronização automática de contas de usuário e associações a grupos de um provedor de identidade para uma aplicação, pelo padrão SCIM 2.0. O IdP chama uma API REST da aplicação para criar usuários, atualizar atributos, ajustar a associação a grupos e desativar contas quando as pessoas saem. As mudanças de identidade são feitas uma única vez no IdP e se propagam para todos os lugares, em vez de serem repetidas manualmente em cada ferramenta.
Qual é a diferença entre o provisionamento SCIM e o JIT?
O JIT cria um usuário na primeira vez em que ele faz login via SSO, e não faz mais nada. O SCIM roda continuamente e de forma independente dos logins, então também cuida de atualizações, associação a grupos e desativação. O JIT resolve o onboarding; o SCIM resolve o ciclo de vida completo. Com o JIT, o desprovisionamento continua sendo um processo manual que alguém precisa assumir.
Como configuro o provisionamento SCIM no TrueFoundry?
Configure primeiro o SSO e depois ative o SCIM em Settings → Security & Access → Provisioning. Expanda a configuração de SSO para copiar a SCIM Base URL, clique no ícone de chave para gerar um token Bearer e cole os dois no seu IdP com o método de autenticação definido como Bearer Token. Atribua usuários e grupos no IdP e eles aparecerão em poucos minutos. No Entra ID e no Okta, o SCIM se apoia em uma configuração de SSO com SAML.
Posso implantar o TrueFoundry na minha própria VPC ou on-prem?
Sim. O TrueFoundry é executado na sua VPC, on-prem, em ambiente air-gapped ou híbrido, de modo que os prompts e as respostas nunca saem do seu domínio, mesmo quando você roteia entre muitos provedores.
O TrueFoundry oferece suporte a MCP e a agentes de IA em geral?
Sim. Ele inclui um MCP Gateway, um Agent Gateway e um MCP & Agents Registry com controle de acesso em nível de ferramenta. Agentes criados com LangGraph, CrewAI, AutoGen ou um framework próprio podem ser governados de forma centralizada.
Ele se integra com a minha stack de observabilidade existente?
Sim. O gateway é compatível com OpenTelemetry e se integra com Grafana, Datadog, Prometheus ou a sua stack preferida. Ele rastreia cada requisição, do prompt à execução da ferramenta e do modelo, para que você obtenha logs unificados sem precisar remover o que você já usa.
