Primeiro o essencial: antes de ligar o SSO no seu WMS, OMS e TMS, não comece pela documentação do protocolo. Passe uma tarde montando uma planilha de três colunas — pessoa, função em cada sistema, quem desativa a conta quando ela sair. Se você não consegue preencher essa planilha, tanto faz se escolhe SAML ou OIDC. Vi esse fracasso se repetir três vezes, e o ponto de ruptura é sempre o mesmo: o provedor de identidade conecta limpo, e o mapeamento de funções do lado do negócio está uma bagunça.
Por que isso sempre explode na véspera do go-live
Setembro de 2023. Um 3PL de 60,000 pés quadrados no sul da Califórnia, entrando no ar com WMS, OMS e TMS na mesma semana. Para simplificar, o cliente deu ao chão um único usuário e senha compartilhados nos três sistemas. Parece eficiente, né?
Explodiu no terceiro dia. Um representante de atendimento que podia ver pedidos no OMS também conseguia editar tarifas de transportadoras no TMS — porque a função "CSR" significava coisas completamente diferentes em cada sistema, e o login compartilhado herdava as permissões mais amplas dos três. O dono me perguntou: "Isso não é o single sign-on? Por que está ficando pior?" Minha resposta: isso não é single sign-on. É um ponto único de falha com tela de login.
O jeito que salvamos foi feio, mas funcionou: congelamos cerca de 40 contas compartilhadas de um dia para o outro, reconstruímos 120 contas individuais mapeadas pessoa–sistema–função, colocamos o negócio para rodar e depois passamos duas semanas alinhando as matrizes de funções e ligando tudo a uma única fonte de identidade. Esse projeto me marcou uma lição: o SSO responde "quem é você". A autorização responde "o que você pode fazer". São dois problemas diferentes, e nunca se deve terceirizar o segundo para o primeiro.
O checklist: do zero ao SSO, passo a passo
Passo 1: Invente todas as contas. Exporte todas as contas dos três sistemas para uma planilha com três colunas: usuário, sistema, função atual. Sinalize três tipos — contas zumbis de funcionários que saíram (quase todo projeto tem 5–10% delas), logins "públicos" compartilhados (os mais comuns nos tablets de picking) e "contas deus" com privilégios demais. Se não forem limpas antes do go-live, o SSO não muda nada.
Passo 2: Monte a matriz de mapeamento de funções. As linhas são funções de negócio (picker, CSR, dispatcher, supervisor de armazém, financeiro, admin de TI); as colunas são os três sistemas; cada célula diz exatamente quais botões aquela função pode clicar naquele sistema. Cuidado: um "dispatcher" no TMS e um "dispatcher" no WMS provavelmente não são a mesma coisa. Mesmo nome, poderes diferentes. Peça ao dono do negócio para assinar essa planilha. Sem assinatura, sem go-live.
Passo 3: Escolha sua fonte de identidade. Se a empresa já tem um sistema corporativo de identidade, use-o como provedor de identidade — não construa um segundo. Só se não houver nada em pé você passa para a decisão de protocolo do passo 4.
Passo 4: Escolha o protocolo. Sistemas novos: OIDC primeiro. Sistemas legados: confira o suporte a SAML 2.0. Muitos produtos WMS tradicionais só falam SAML — não force OIDC neles nem reescreva o código deles. As tocas de coelho da adaptação de protocolo são mais fundas do que parecem.
Passo 5: Mapeie os atributos de usuário. Decida o que o provedor de identidade passa adiante: ID de funcionário, e-mail, departamento, função. Passe pelo menos um identificador estável e globalmente único — o ID de funcionário, não o e-mail, porque e-mails são renomeados. Para cada campo, nomeie a fonte autoritativa: departamento vem do RH, ponto final.
Passo 6: Ligue o fluxo de offboarding. A desativação de contas precisa se enganchar no processo de desligamento do RH, com a meta "desativado no último dia". Não dá para automatizar? Então a TI reconcilia manualmente a lista de desligamentos toda sexta à tarde. Vi esse buraco três vezes. No início de 2024, um armazém de e-commerce de artigos para casa fez uma auditoria de permissões seis meses depois de um lançamento limpo de SSO e descobriu que um dispatcher que tinha pedido demissão três meses antes ainda conseguia entrar no TMS e consultar tarifas de transportadoras — porque ninguém jamais sincronizou a lista de desligamentos do RH com a TI.
Passo 7: Role por etapas. Piloto com 5–10 pessoas de TI por uma semana, depois um armazém, depois todo mundo. Mantenha o caminho de login antigo disponível como rollback durante o piloto — essa linha fica no topo do meu checklist da noite de go-live, permanentemente.
Faça as contas primeiro: SAML vs OIDC vs contas próprias
| SAML 2.0 | OIDC | Contas próprias | |
|---|---|---|---|
| Ideal para | Sistemas legados, WMS/ERP tradicionais | Sistemas novos, apps cloud-native | Times pequenos com um ou dois sistemas |
| Esforço de implementação | Médio (config XML verbosa) | Menor (JSON, ecossistema maduro) | Baixo no início, alto depois |
| Manutenção contínua | Baixa (padrão maduro) | Baixa | Alta (política de senha, auditoria, MFA — tudo DIY) |
| Suporte móvel/tablet | Fraco | Forte | Depende do seu código |
| Custo total a longo prazo | Velho mas estável | Escolha padrão em projetos novos | Dá prejuízo além de dois sistemas — não |
O framework de decisão é simples: se algum dos três sistemas só suporta SAML, vá tudo em SAML. Todos os sistemas são novos? OIDC. Considere contas próprias só se tiver certeza de que não vai passar de dois sistemas nos próximos dois anos. O custo real de um sistema de contas próprio não é a construção — é o dia em que você conecta o sistema número quatro e descobre que os três primeiros inventaram cada um sua própria política de senha.
Checklist da noite de go-live: toda falha mora aqui
- Apague as contas de teste. Quase todo projeto encontra de três a cinco contas estilo test01 ainda vivas na véspera do go-live.
- Não passe as contas de admin pelo SSO. Mantenha pelo menos uma conta local de superadmin por sistema para o dia em que o provedor de identidade cair. Escreva a senha no papel e tranque no cofre — sim, é primitivo, e sim, já salvou um go-live.
- Alinhe os tempos de sessão nos três sistemas. WMS em 8 horas e TMS em 30 minutos vão enlouquecer os dispatchers. Padronize em 4–8 horas, com uma política separada para os tablets da alta temporada que nunca bloqueiam.
- Teste o cenário de zona morta. Quando o Wi-Fi do armazém cai, a página de redirecionamento do SSO não carrega no tablet e o picker fica parado na frente do rack olhando para o nada. O fallback em modo degradado precisa ser testado de verdade, no chão de verdade.
- Garanta que os logs de auditoria possam ser juntados. Quando algo quebrar, você precisa responder "o que esse usuário mudou no TMS ontem às 2 p.m." — e os logs dos três sistemas precisam carregar o mesmo identificador de usuário.
Uma nota contrária para fechar: muita gente se sente mais segura depois que o SSO entra no ar. A verdade vai para o outro lado — o SSO transforma "uma chave, uma porta" em "uma chave, três portas", então uma chave perdida custa três vezes mais. MFA não é opcional com SSO; é parte do pacote. Fricção demais? Então aplique pelo menos para as funções de admins e financeiro.
Uma coisa que você pode fazer amanhã: exporte as contas dos três sistemas e disponha nas três colunas do passo 1. A primeira verdade que você vai descobrir geralmente é esta — as 80 contas que você achava que tinha são na verdade 110.
Por Lin Xiao, Consultora de Implementação WMS
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
