SSO com SAML 2.0 no Setor Financeiro: Implementação Enterprise

O setor financeiro tem um problema estrutural de identidade: dezenas de portais, plataformas internas, aplicações de parceiros comerciais e serviços em nuvem, cada um com o próprio sistema de autenticação. A proliferação de credenciais favorece a reutilização delas e fluxos de recuperação fracos; o SSO reduz essa superfície, mas não elimina por si só o phishing nem o sequestro de sessão: deve ser acompanhado de MFA e de controles de sessão.

SAML 2.0 e OpenID Connect: quando convém cada um

O OAuth 2.0 delega autorização; o OpenID Connect acrescenta autenticação. SAML 2.0 e OIDC estão ambos vigentes: o SAML continua frequente em suítes corporativas e na federação B2B existente; o OIDC costuma ser preferível para aplicações web e móveis modernas e para APIs. O SAML 2.0 foi concebido para a federação de identidade entre organizações, com asserções XML assinadas com certificados X.509 e atributos de usuário complexos, e mantém presença relevante em ambientes corporativos; a escolha depende de compatibilidade, padrão de integração, modelo de ameaças e operação.

Em sistemas centrais e plataformas legadas, a federação costuma exigir um portal, gateway ou camada intermediária; valida-se por produto e versão o fluxo suportado, a sessão e os atributos disponíveis. Ambos podem exigir componentes de integração; o impacto é medido na arquitetura concreta.

Arquitetura de uma implementação real

No portal de vales da Intelyvale, os clientes corporativos entram com a conta da própria empresa: federamos o provedor de identidade deles e separamos esse acesso do login local.

Os problemas que ninguém menciona

A implementação técnica do SAML é relativamente direta com bibliotecas maduras. Os problemas reais aparecem na operação real: rotação de certificados (se o IdP troca o certificado sem avisar os SPs, os usuários ficam bloqueados; com metadados, a rotação é automatizada), atributos inconsistentes (diferentes SPs esperam o mesmo atributo com nomes diferentes), o mapeamento dos papéis do diretório do cliente para os do sistema, o cadastro de usuários no primeiro acesso e o encerramento de sessão em ecossistemas híbridos.

As asserções dependem de condições de tempo (NotBefore / NotOnOrAfter); a tolerância é definida explicitamente, tão reduzida quanto a operação permitir, com sincronização de horário monitorada.

O provedor de serviço valida de forma estrita assinatura e cadeia de confiança, emissor, audiência, destino, vigência, correspondência com a requisição e uso único da asserção, e se protege contra repetição e XML signature wrapping. Aceitar uma asserção “assinada” não basta.