A Resposta Breve
A arquitetura de identidade no Salesforce não é um projeto técnico pontual, mas sim uma camada de controle que se executa diariamente: quem acessa, com qual identidade, com quais permissões, e o que acontece no momento em que o acesso não deveria mais ser permitido. A escolha entre SAML e OIDC, JIT e SCIM, e entre políticas de MFA no nível do IdP versus aplicação interna no Salesforce – tudo isso pode parecer detalhes de configuração, mas na prática, determina quanto tempo leva para bloquear o acesso de um funcionário desligado e qual fração desses incidentes só será descoberta em auditoria.
A abordagem correta não começa com o protocolo, mas com duas perguntas: quem é a fonte da verdade para a identidade do usuário, e qual é o tempo máximo permitido entre um evento de Offboarding e o bloqueio efetivo do acesso. A partir daí, todas as outras decisões são derivadas – o tipo de Federação, o método de Provisionamento, a política de Sessão e o processo de Break Glass.
Organizações que também consideram a questão das permissões em si, e não apenas a autenticação, encontrarão mais informações no Modelo de Permissões do Salesforce.
Mapa de Decisões: Quatro Camadas de Identidade no Salesforce
| Camada | Pergunta a Decidir | Principais Opções | O que Falha se a Decisão For Errada |
|---|---|---|---|
| Federação e Autenticação | Quem é o IdP e como o Salesforce confia nele | SAML 2.0, OIDC, Autenticação Delegada | Login duplicado, incompatibilidade de Atributos, quebra de confiança |
| Provisionamento e Ciclo de Vida | Como o usuário é criado, atualizado e cancelado | Provisionamento JIT, SCIM, criação manual | Contas órfãs, acesso remanescente após desligamento |
| Sessão e MFA | Onde o nível de autenticação e a duração da Sessão são aplicados | MFA no IdP, MFA interno no Salesforce, Políticas de Sessão | Bypass de MFA por caminho alternativo, Sessão que nunca expira |
| Break Glass e Auditoria | O que acontece se o SSO falhar e quem verifica anomalias | Usuário de emergência controlado, Histórico de Login, Event Monitoring | Dependência total do IdP, incapacidade de investigação retrospectiva |
SAML vs. OIDC: Não é Uma Questão de "O que é Mais Novo"
A escolha entre os dois protocolos não deve ser ditada por tendências, mas sim pela infraestrutura existente. SAML opera com XML e Assertions assinadas, sendo comum em organizações com Active Directory Federation Services ou um IdP estabelecido que já serve dezenas de outros sistemas. OIDC é construído sobre o OAuth 2.0, é mais leve para manter e particularmente conveniente quando o mesmo IdP precisa atender tanto a consumidores de API modernos quanto ao login de usuários.
O erro comum é escolher com base no que parece "avançado" sem verificar quais Atributos o IdP existente já envia, e como eles são mapeados para o Salesforce (Username, Federation ID, Profile, Permission Set Group). Um mapeamento de Atributo incorreto na fase de configuração geralmente leva à correção manual de dezenas de usuários em produção, e não apenas à alteração de uma configuração.
Um ponto frequentemente esquecido: mesmo ao escolher OIDC ou SAML, é bom planejar o Login Iniciado pelo IdP vs. o Iniciado pelo SP separadamente – alguns dos incidentes de segurança mais comuns resultam de o Login Iniciado pelo SP permanecer aberto, mesmo que todo o processo de login tenha sido planejado exclusivamente através do portal do IdP.
Provisionamento JIT vs. SCIM: Quando "No Momento do Login" Não é Suficiente
O Provisionamento JIT (Just-In-Time) cria ou atualiza o usuário no Salesforce no momento do primeiro login, com base nos dados que chegam do IdP na SAML Assertion ou no OIDC Token. É conveniente, barato de implementar e suficiente para a maioria das organizações onde os usuários fazem login regularmente.
O problema: o JIT não resolve o Deprovisionamento. Se um funcionário é removido do IdP, mas não faz mais login, sua conta permanece ativa no Salesforce indefinidamente, pois não há um evento que acione uma atualização. É exatamente aqui que o SCIM (System for Cross-domain Identity Management) entra – ele permite a sincronização proativa do IdP com o Salesforce, incluindo a desativação imediata quando um usuário é removido na origem.
A regra prática: se a organização tem um requisito de Offboarding em horas, e não em dias – subcontratados, funcionários temporários, acesso a dados sensíveis –, o SCIM não é um "seria bom ter", mas uma exigência de Compliance. Se o ciclo de funcionários é lento e a Governança já inclui uma revisão trimestral de acessos, o JIT por si só pode ser suficiente, desde que seja acompanhado por um processo manual documentado para bloqueio imediato.
O planejamento do provisionamento deve sempre ser avaliado também em relação à complexidade da automação relacionada – por exemplo, quando Flows que executam lógicas de atribuição de permissões no momento da criação do usuário estão envolvidos, onde a comparação entre Flow e Apex é relevante para identificar onde o código customizado vale a pena.
MFA e Política de Sessão: Duas Camadas, Não Apenas Uma
Um erro comum é satisfazer-se com o MFA aplicado no Identity Provider e assumir que ele cobre todos os caminhos de acesso ao Salesforce. Na prática, enquanto houver um usuário que pode se conectar diretamente via login.salesforce.com – por exemplo, uma integração, um Usuário de API, ou um Administrador que mantém acesso de backup – é necessária uma política de MFA separada definida dentro do próprio Salesforce (Verificação de Identidade, Níveis de Segurança de Sessão).
Além disso, a política de Sessão determina coisas fáceis de perder: Tempo Limite de Sessão, "Forçar logout no tempo limite da sessão", Intervalos de IP de Login e Sessão de Alta Confiança obrigatória para operações sensíveis (por exemplo, alteração de permissões ou exportação massiva de dados). Uma organização que define um MFA forte, mas mantém o Tempo Limite de Sessão no padrão de duas horas, abre uma janela em que um computador roubado mantém acesso ativo muito além do tempo razoável.
Break Glass e Auditoria: Quando o SSO Falha, Quem Acessa
A dependência total de um IdP externo cria um ponto único de falha: se o IdP falhar ou se houver um bug na configuração da Federação, ninguém consegue fazer login, incluindo quem precisa corrigir o problema. A solução comum é um usuário Break Glass – uma conta de superadministrador com autenticação independente (não dependente do SSO), senha gerenciada em um cofre (Vault) e não na memória de uma pessoa, e MFA separado.
É importante notar: Break Glass não é um "backdoor conveniente" – é um mecanismo de emergência controlado. Seu uso deve acionar um alerta automático e ser revisado dentro de um dia útil por uma entidade diferente da que o utilizou. Muitas organizações configuram o usuário corretamente, mas esquecem o controle contínuo – a senha não é rotacionada e suas permissões são muito amplas por padrão.
Cenário Corporativo: Falha de Offboarding em uma Seguradora de Médio Porte
Imagine uma companhia de seguros com cerca de seiscentos funcionários, utilizando Okta como Identity Provider e uma configuração SAML para o Salesforce estabelecida há aproximadamente três anos. O Provisionamento é totalmente baseado em JIT: quando um novo funcionário faz login pela primeira vez, uma conta de usuário é criada para ele com Perfil e Grupo de Conjuntos de Permissões de acordo com o grupo Okta ao qual pertence.
Em um dos casos, um representante de serviço foi demitido na sexta-feira à tarde. A equipe de TI o desativou no Okta imediatamente. Na prática, como não havia um mecanismo SCIM ou Webhook para sincronizar a desativação com o Salesforce, a conta dele permaneceu no estado Ativo lá – e como a sessão dele já estava ativa desde a manhã e "Force logout on session timeout" não estava configurado, ele continuou a acessar o sistema mesmo depois da demissão, até que alguém notou em uma revisão semanal de acessos na segunda-feira.
A solução implementada não foi uma transição completa para SCIM (que exigiria um projeto separado e orçamento de integração), mas sim a combinação imediata de três ações: ativação de "Force logout on session timeout" para todos os perfis sensíveis, redução do Tempo Limite de Sessão de 120 minutos para 30 minutos para cargos de atendimento ao cliente, e a adição de uma etapa automática no processo de Offboarding organizacional que executa a desativação direta no Salesforce como uma ação independente, e não apenas como um resultado indireto da desativação no Okta. O SCIM permaneceu como meta para o próximo trimestre, já com orçamento e aprovação, mas a lacuna mais perigosa foi fechada em uma semana.
Riscos Comuns e Ações Preventivas
| Risco | Como se Manifesta na Prática | Ação Preventiva |
|---|---|---|
| Dependência total de JIT sem Desprovisionamento | Usuários desligados permanecem Ativos indefinidamente | Adição de etapa de Offboarding independente no Salesforce, não dependente de sincronização |
| MFA apenas no IdP | Usuários de integração e Administradores ignoram MFA via login direto | Política de MFA interna no Salesforce para todos os tipos de usuários |
| Tempo Limite de Sessão muito longo | Computador roubado ou sessão esquecida aberta mantém acesso por horas | Redução do Tempo Limite e Force Logout para perfis sensíveis |
| Break Glass sem controle | Uso da conta de emergência não é detectado a tempo | Alerta automático e revisão dentro de um dia útil para qualquer uso |
| Mapeamento de Atributos incorreto do IdP | Usuário obtém Perfil ou Role incorretos no primeiro login | Verificação completa do mapeamento em ambiente Sandbox antes da mudança para Produção |
- ☐ Um único Identity Provider foi definido como fonte da verdade, e o que acontece quando ele falha é conhecido.
- ☐ O protocolo (SAML ou OIDC) foi escolhido com base na infraestrutura existente, e não em tendências.
- ☐ O mapeamento de Atributos entre o IdP e o Perfil/Grupo de Conjuntos de Permissões foi testado no Sandbox.
- ☐ Uma política clara foi definida: JIT apenas, ou JIT combinado com SCIM conforme a exigência de Offboarding.
- ☐ O MFA é aplicado também dentro do Salesforce, não apenas no IdP.
- ☐ O Tempo Limite de Sessão e o Force Logout são configurados de acordo com a sensibilidade do perfil.
- ☐ Existe um usuário Break Glass controlado, com MFA separado e senha armazenada em cofre.
- ☐ O processo de Offboarding inclui uma etapa independente para desativação no Salesforce.
- ☐ O Histórico de Login e o Event Monitoring são verificados em um cronograma regular.
- ☐ Existe um plano de revisão periódica (Access Review) que não depende apenas da memória da equipe de TI.
Como Avaliar o Desempenho da Arquitetura
O principal indicador não é "se o SSO está ativo", mas sim o tempo de resposta entre um evento na fonte autoritativa e a mudança correspondente no Salesforce: quanto tempo se passa entre a remoção de um usuário no IdP e a desativação efetiva. Um indicador complementar é a taxa de logins realizados por um caminho inesperado (Login Direto em vez de via IdP), que deve tender a zero, exceto para usos documentados do Break Glass. Um terceiro indicador é a frequência da revisão das permissões em relação ao status real – nem toda mudança organizacional chega via IdP, e, por isso, uma revisão trimestral continua sendo essencial, mesmo com provisionamento automático completo.
Para a implementação ou auditoria de uma arquitetura de identidade em um ambiente Salesforce existente, é possível avançar através de serviço de arquitetura de CRM. Organizações que também examinam a conexão com o ERP e sistemas de folha de pagamento como parte do quadro geral de identidade encontrarão informações complementares em Conexão do Salesforce com ERP e um panorama arquitetural mais amplo no Guia de Arquitetura de CRM.
Conclusão
A arquitetura de identidade no Salesforce é construída uma única vez, mas testada diariamente por incidentes isolados – um funcionário que se desliga, uma sessão esquecida aberta, uma integração que ignora o MFA. As escolhas críticas (SAML vs. OIDC, JIT vs. SCIM, MFA duplo, Break Glass controlado) não devem ser ditadas por configurações padrão do IdP, mas sim pelo tempo de resposta necessário para bloquear o acesso e pelo nível de sensibilidade dos dados expostos. Uma organização que planeja essa camada antecipadamente, em vez de descobrir as lacunas em uma auditoria ou após um incidente de segurança, economiza tanto custos de correção quanto riscos reputacionais e regulatórios.