SAML e federação

SAML (Linguagem de Marcação de Asserções de Segurança) é um padrão baseado em XML para trocar dados de autenticação e autorização, predominante no SSO empresarial.

• Ele permite que um provedor de identidade corporativo ateste a identidade de um usuário para muitos aplicativos.
• O SAML 2.0 é anterior ao OIDC e continua profundamente enraizado na identidade B2B e da força de trabalho.

Compreender o SAML é essencial para proteger a federação empresarial, na qual uma única falha de confiança expõe todos os aplicativos conectados.

A federação SAML tem duas partes principais.

• O Provedor de identidade (IdP) autentica o usuário e emite asserções (Okta, Entra ID, Ping).
• O Provedor de serviços (SP) é o aplicativo que confia no IdP e concede acesso.

A confiança é estabelecida fora de banda pela troca de metadados, incluindo certificados de assinatura e URLs de pontos de acesso.

O artefato central é a asserção, um documento XML que declara que o IdP autenticou um sujeito.

• O Sujeito identifica o usuário (NameID).
• As Condições definem a janela de validade e o público pretendido.
• O AuthnStatement registra como e quando a autenticação ocorreu.
• O AttributeStatement transporta funções, e-mail e declarações de grupos.

O padrão mais comum é o SSO iniciado pelo SP.

• O usuário acessa o SP, que gera uma AuthnRequest e redireciona para o IdP.
• O IdP autentica o usuário e envia por POST uma Response assinada de volta ao Serviço Consumidor de Asserções (ACS) do SP.
• O SP valida a asserção e cria uma sessão local.

A segurança do SAML se baseia em assinaturas digitais XML. O IdP assina a asserção (e/ou a resposta) com sua chave privada; o SP verifica usando o certificado confiável.

• Assine a asserção em si, não apenas a resposta externa.
• Verifique a assinatura usando um certificado do IdP fixado proveniente dos metadados, não um certificado incorporado à mensagem.

A maioria dos ataques SAML tem como alvo a lógica de validação de assinaturas.

O envelopamento de assinatura XML é a classe de ataque de assinatura do SAML. O invasor mantém um elemento validamente assinado, mas adiciona uma segunda asserção forjada que a lógica do aplicativo realmente lê.

• A assinatura continua sendo verificada contra o fragmento original.
• Mas a lógica de negócio processa a asserção injetada e não assinada.

Mitigação: use uma biblioteca SAML reforçada, valide se o elemento assinado é o que será consumido e rejeite documentos com várias asserções ou asserções ambíguas.

Uma asserção deve estar vinculada ao SP pretendido. O SAML fornece restrições explícitas.

• AudienceRestriction nomeia o ID da entidade do SP para o qual a asserção é válida.
• O destinatário em SubjectConfirmation deve corresponder à URL do ACS.

O SP deve impor essas restrições. Ignorar a verificação do público permite que uma asserção criada para um aplicativo seja repetida em outro.

As asserções são credenciais de curta duração e uso único. Os SPs devem impor isso.

• Respeite NotBefore e NotOnOrAfter com um desvio mínimo do relógio.
• Acompanhe o ID da asserção e rejeite qualquer reutilização durante a janela de validade.
• Exija TLS no ponto de acesso do ACS.

Sem rastrear repetições, uma asserção capturada pode ser enviada novamente antes de expirar.

Federação amplia o SSO entre limites organizacionais, às vezes por meio de intermediários que traduzem entre protocolos.

• Cada vínculo de confiança é um possível ponto fraco; um provedor de identidade comprometido pode se passar por qualquer usuário.
• Intermediários de identidade podem conectar SAML e OIDC, exigindo um mapeamento cuidadoso das declarações.

Aplique o princípio do menor privilégio ao mapeamento de atributos e monitore novos registros inesperados de SP.

Vale a pena auditar os seguintes modos recorrentes de falha do SAML:

• Assinatura não verificada ou resposta assinada, mas asserção não assinada.
• Vulnerabilidade a encapsulamento de assinatura XML.
• Ausência de verificações de público-alvo/destinatário.
• Ausência de proteção contra repetição ou janelas de validade excessivamente longas.
• Análise de Entidade Externa XML (XXE) no SP.
• Confiança no certificado incorporado à mensagem em vez de nos metadados fixados.

Ambos oferecem SSO, mas diferem em sua concepção.

• SAML usa XML, vinculações de POST/redirecionamento no navegador, é comum em ambientes corporativos e conta com ferramentas maduras.
• OIDC usa JSON/JWT, é compatível com REST e mais adequado para dispositivos móveis e SPAs.

Muitas organizações usam ambos. Os responsáveis pela defesa devem conhecer as regras de validação de asserções do protocolo usado por cada aplicativo, pois a superfície de ataque é diferente.

Selecione a melhor defesa para o ataque descrito.

Principais conclusões:

• SAML é um SSO empresarial baseado em XML entre um provedor de identidade e um SP, usando asserções assinadas.
• A segurança depende da validação da assinatura XML correta com base em um certificado fixado.
• Proteja-se contra encapsulamento de assinatura XML, repetição e XXE.
• Sempre imponha restrições de público-alvo/destinatário e janelas de validade.
• A federação amplia a confiança, mas multiplica o raio de impacto de um provedor de identidade comprometido.