Como este tema funciona na sua empresa
Federação formal não existe. Acesso de parceiros é através de contas separadas (manual, tedioso). Cada parceiro tem username/password próprio. Desafio: gerenciar múltiplas contas, renovar senhas, revogar quando parceria termina. Segurança é menor (reutilização de senhas, credenciais compartilhadas).
Federação com 1-2 parceiros estratégicos. Implementação via SAML ou OIDC. Parceiro autentica em seu IdP, recebe token, acessa sistema seu. Simplifica gerenciamento (menos senhas corporativas), mas exige setup de confiança bilateral. Revogação é desafio: quando usuário parceiro sai, como você sabe revogar?
Federação com múltiplos parceiros (fornecedores, clientes, acquisições). Políticas explícitas de acesso federado. Integração com HR data de parceiro para sincronizar saídas. Modelo de governança claro: quem aprova acesso federado, quem é responsável por segurança, SLA de revogação.
Federação de identidade permite que usuários de uma organização acessem sistemas de outra sem criar conta separada. Usa protocolos como SAML ou OIDC para estabelecer confiança bilateral entre IdP (Identity Provider) de ambas organizações. Essencial para B2B moderno, mas introduz risco: você confia na qualidade de autenticação do IdP parceiro.
Como funciona federação de identidade
Conceito é simples: Organização A (seu IdP) confia em identidades de Organização B (seu cliente ou parceiro). Quando usuário de B tenta acessar sistema de A, A valida token emitido por B, em vez de exigir nova senha. Processo:
- Setup de confiança: A e B trocam metadados de segurança (certificado, endpoints, políticas). Podem ser bilaterais (ambos confiam) ou unilaterais (apenas A confia em B).
- Autenticação do usuário: Usuário de B autentica em IdP de B (seu próprio AD, Okta, Google Workspace).
- Emissão de token: IdP de B emite SAML assertion ou JWT token, assinado com chave privada de B.
- Acesso a sistema A: Usuário tenta acessar sistema de A, apresenta token de B.
- Validação: Sistema A valida token (verifica assinatura, expiration, trusted issuer). Se válido, concede acesso.
Protocolo típico: SAML 2.0 para B2B corporativo (CIO to CIO), OIDC para moderno (SaaS a SaaS)
Modelos de confiança: bilateral, unilateral, guest account
Full federation (bilateral): Org A confia em Org B completamente. Identidade de usuário B é reconhecida como legítima. Acesso é direto (usuário B acessa recurso A com mesmo username). Risco máximo: se IdP B for comprometido, seus dados estão em risco.
Unilateral: Org A confia em Org B, mas usuário B não tem acesso direto. Org A cria conta "guest" e mapeia identidade B para guest. Exemplo: "usuário [email protected]" é mapeado para "guest_clienteb_joao" em Org A. Risco reduzido: usuário B não acessa como "própria identidade", mas como guest com permissões limitadas.
Guest account federado: Híbrido. IdP B autentica usuário; Org A mapeia para guest local com permissões específicas. Permite revogação granular: Org A pode revogar guest sem coordenação com B.
Governança de acesso federado
Pergunta crítica: quem é responsável por segurança? Resposta deve estar em contrato. Org A é responsável por: Validar token de B, manter confiança, revogar acesso guest se abuse. Org B é responsável por: Autenticar seus usuários, revogar acesso quando usuário sai, notificar A de saída. Falta de clareza causa gaps: usuário sai de B, mas continua com acesso em A porque A não soube.
Solução: contrato que especifica SLA de revogação (ex: "Org A revoga acesso em 24h após notificação de Org B"). Integração de HR data (Org B envia feed de saídas para Org A diariamente) é ideal.
Revogação: o desafio crítico
Revogação em federação é mais lenta que sistema local. Se usuário sai de Org B, B pode revogar acesso a seus próprios sistemas imediatamente; mas A ainda confia no token de B até expiration. Exemplo: token de usuário expires em 8 horas. Se usuário sai às 14h, mas token não expira até 22h, usuário tem 8 horas de acesso indevido a A.
Mitigações:
- Validação de revogação em tempo real: A valida com B se usuário ainda está ativo (protocol: token revocation endpoint). Lento, mas seguro.
- Token com vida curta: Token expira em 15-30 minutos em vez de 8 horas. Usuário revogado não consegue renovar. Reduz janela de acesso indevido.
- Feed automático de saídas: B envia daily feed de usuários saídos; A revoga automaticamente. SLA: revogação em <24h.
Conformidade (LGPD) e federação
LGPD trata parceiro como "processador de dados" (se processa dados pessoais em nome de A). Confiança em IdP fraco de B é risco de conformidade: se B for hack, dados pessoais A são expostos. Requisitos LGPD: Parceiro (B) deve ter segurança adequada (auditoria, criptografia, backup). Contrato deve especificar responsabilidades. Não é "confie cegamente em B"; é "confie em B, mas valide periodicamente"[1].
Casos de uso de federação por contexto
Cliente X usa seu SaaS. Usuários de X autenticam com próprio IdP (AD, Okta), acessam SaaS seu. Federação simplifica: X não precisa duplicar credenciais, você não precisa gerenciar senhas de X. Exemplo: Salesforce, Slack, Jira via SAML.
Empresa A adquire B. Usuários de B precisam acessar sistemas de A durante transição. Federação permite acesso transitório sem duplicar contas. Após 6-12 meses, B é migrada para IdP de A (descontinua federação).
Plataforma A oferece multi-tenant: cada cliente traz próprio IdP. Plataforma confia em múltiplos IdP de clientes. Cada tenant é isolado (dados de cliente X não vazam para Y). SAML é padrão de facto para multi-tenant federado.
Fallback: e se IdP federado ficar offline?
Risco real: Org B tem outage de IdP. Usuários de B não conseguem autenticar em A porque A não consegue validar token de B. Contingência: (1) Token com vida longa: Token dura 8 horas; mesmo se B offline, sessão ativa continua. (2) Guest account local: Org A cria conta guest para casos de emergência. (3) SLA de B: Contrato exige que B mantenha IdP em >99,5% uptime; compensação se falhar.
SAML vs. OIDC em federação
SAML 2.0: Padrão B2B corporativo. Assertions XML assinadas. Bom para integração on-premise, complexa mas robusta. Usado em enterprise. OIDC (OpenID Connect): Moderno. JWT tokens. Mais simples, melhor para SaaS. Protocolo RESTful. Crescimento em adoção.
Escolha: se empresa é grande e on-premise heavy, SAML. Se é SaaS/cloud-native, OIDC.
Sinais de que federação é necessária
Se você se reconhece em três ou mais cenários abaixo, federação pode reduzir overhead.
- Você tem 3+ parceiros B2B que frequentemente precisam de acesso a sistemas seus
- Gerenciamento de contas de parceiro é manual e tedioso
- Revogação de acesso de parceiro é lenta (leva dias para confirmar)
- Parceiros pedem para usar próprio IdP ("somos Cloud, queremos SSO")
- Compliance exige rastreabilidade de quem acessou o quê (federação com audit)
- Volume de projetos B2B está crescendo (acquisições, parcerias)
Caminhos para implementar federação de identidade
Implementação pode ser feita internamente ou com suporte especializado.
Viável se time tem experiência em IAM/SAML.
- Etapas: Selecionar IdP corporativo (Azure AD, Okta, Ping), definir modelo de confiança, setup de SAML/OIDC, validação com parceiro pilot
- Tempo estimado: 6-12 semanas para primeira integração; 2-3 semanas para integração adicional
- Risco: SAML é complexo; erros de configuração podem expor dados ou negar acesso legítimo
Recomendado para primeira implementação ou setup complexo.
- Tipo de fornecedor: Consultoria IAM, integradores de identidade
- Escopo: Design de modelo de confiança, implementação de SAML/OIDC, validação de segurança, governance framework
- Tempo: 8-16 semanas
- Vantagem: Expertise em segurança de federação, validation de conformidade
Precisa de ajuda para estruturar federação de identidade?
Se sua empresa está avaliando B2B federation ou quer implementar SAML/OIDC com parceiros, o oHub conecta você gratuitamente a especialistas em IAM e identidade federada. Em menos de 3 minutos, descreva seu cenário e receba propostas.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe recomendações e pode solicitar design inicial.
Perguntas frequentes
O que é federação de identidade?
Federação permite usuários de organização A acessar sistemas de organização B sem criar conta separada. B autentica seu usuário, emite token, A confia no token e concede acesso. Essencial em B2B moderno.
Como funciona autenticação entre empresas parceiras?
Processos: (1) Org A e B estabelecem confiança (trocam certificados, metadados). (2) Usuário de B autentica em IdP de B. (3) B emite SAML assertion ou JWT token. (4) Usuário acessa sistema A, apresenta token. (5) A valida token, concede acesso. Sem necessidade de senha adicional.
Federação é segura para compartilhar acesso com terceiros?
Sim, se bem implementada. Requisitos: (1) Confiança bilateral com criptografia. (2) Validação de token em tempo real. (3) SLA de revogação. (4) Auditoria de acesso. (5) Conformidade do parceiro verificada. Risco principal: confiar em IdP fraco do parceiro.
Qual é a diferença entre federação e integração direta?
Federação: você confia em IdP do parceiro; ele autentica, você valida. Integração direta: você gerencia conta do parceiro. Federação é melhor (menos overhead, melhor segurança), mas exige confiança mútua.
Como implementar federação com múltiplos parceiros?
Passo 1: Selecionar IdP corporativo com suporte SAML/OIDC. Passo 2: Definir modelo de governança (bilateral, unilateral, guest). Passo 3: Setup com primeiro parceiro (pilot). Passo 4: Replicar para parceiros adicionais. Ferramentas: Okta, Azure AD, Ping Identity.
Federação impacta segurança e conformidade?
Impacto positivo: menos senhas, melhor auditoria. Impacto negativo: dependência de IdP do parceiro (se comprometido, você está em risco). Conformidade (LGPD): parceiro deve ter segurança adequada; contrato deve especificar responsabilidades de cada parte.