Visão Geral do SAML

Security Assertion Markup Language (SAML) permite que provedores de identidade (IdP) sejam utilizados para enviar credenciais de autorização para provedores de serviço (SP), facilitando o single sign-on (SSO). Essa abordagem simplifica a gestão de múltiplos logins ao permitir que um único conjunto de credenciais seja usado em vários sites. Ela utiliza XML para comunicação padronizada entre IdPs e SPs, vinculando a autenticação da identidade do usuário com a autorização de serviço.

Comparação entre SAML e OAuth

• SAML é voltado para fornecer às empresas maior controle sobre a segurança do login SSO.
• OAuth é projetado para ser mais amigável para dispositivos móveis, usa JSON e é um esforço colaborativo de empresas como Google e Twitter.

Fluxo de Autenticação SAML

Para mais detalhes, consulte o post completo em https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/. Este é um resumo:

O processo de autenticação SAML envolve várias etapas, conforme ilustrado no esquema:

1. Tentativa de Acesso ao Recurso: O usuário tenta acessar um recurso protegido.
2. Geração da Solicitação SAML: O SP não reconhece o usuário e gera uma Solicitação SAML.
3. Redirecionamento para o IdP: O usuário é redirecionado para o IdP, com a Solicitação SAML passando pelo navegador do usuário.
4. IdP Recebe a Solicitação: O IdP recebe a Solicitação SAML.
5. Autenticação no IdP: O IdP autentica o usuário.
6. Validação do Usuário: O IdP valida a legitimidade do usuário para acessar o recurso solicitado.
7. Criação da Resposta SAML: O IdP gera uma Resposta SAML contendo as afirmações necessárias.
8. Redirecionamento para a URL ACS do SP: O usuário é redirecionado para a URL do Serviço Consumidor de Afirmações (ACS) do SP.
9. Validação da Resposta SAML: O ACS valida a Resposta SAML.
10. Acesso ao Recurso Concedido: O acesso ao recurso inicialmente solicitado é concedido.

Exemplo de Solicitação SAML

Considere o cenário em que um usuário solicita acesso a um recurso seguro em https://shibdemo-sp1.test.edu/secure/. O SP identifica a falta de autenticação e gera uma Solicitação SAML:

GET /secure/ HTTP/1.1
Host: shibdemo-sp1.test.edu
...

A solicitação SAML bruta se parece com isto:

<?xml version="1.0"?>
<samlp:AuthnRequest ...
</samlp:AuthnRequest>

Elementos-chave desta solicitação incluem:

• AssertionConsumerServiceURL: Especifica onde o IdP deve enviar a SAML Response após a autenticação.
• Destination: O endereço do IdP para o qual a solicitação é enviada.
• ProtocolBinding: Define o método de transmissão das mensagens do protocolo SAML.
• saml:Issuer: Identifica a entidade que iniciou a solicitação.

Após a geração da SAML Request, o SP responde com um 302 redirect, direcionando o navegador para o IdP com a SAML Request codificada no cabeçalho Location da resposta HTTP. O parâmetro RelayState mantém as informações de estado durante a transação, garantindo que o SP reconheça a solicitação de recurso inicial ao receber a SAML Response. O parâmetro SAMLRequest é uma versão comprimida e codificada do trecho XML bruto, utilizando compressão Deflate e codificação base64.

Exemplo de SAML Response

Você pode encontrar uma resposta SAML completa aqui. Os componentes-chave da resposta incluem:

• ds:Signature: Esta seção, uma Assinatura XML, garante a integridade e autenticidade do emissor da asserção. A SAML response no exemplo contém dois elementos ds:Signature, um para a mensagem e o outro para a asserção.
• saml:Assertion: Esta parte contém informações sobre a identidade do usuário e possivelmente outros atributos.
• saml:Subject: Especifica o sujeito principal de todas as declarações na asserção.
• saml:StatusCode: Representa o status da operação em resposta à solicitação correspondente.
• saml:Conditions: Detalha condições como o tempo de validade da Asserção e o Provedor de Serviço especificado.
• saml:AuthnStatement: Confirma que o IdP autenticou o sujeito da Asserção.
• saml:AttributeStatement: Contém atributos que descrevem o sujeito da Asserção.

Após a SAML Response, o processo inclui um 302 redirect do IdP. Isso leva a uma solicitação POST para o URL do Serviço de Consumo de Asserção (ACS) do Provedor de Serviço. A solicitação POST inclui os parâmetros RelayState e SAMLResponse. O ACS é responsável por processar e validar a SAML Response.

Após a solicitação POST ser recebida e a SAML Response ser validada, o acesso é concedido ao recurso protegido inicialmente solicitado pelo usuário. Isso é ilustrado com uma solicitação GET para o endpoint /secure/ e uma resposta 200 OK, indicando acesso bem-sucedido ao recurso.

Assinaturas XML

As Assinaturas XML são versáteis, capazes de assinar uma árvore XML inteira ou elementos específicos dentro dela. Elas podem ser aplicadas a qualquer Objeto XML, não apenas a elementos de Resposta. Abaixo estão os principais tipos de Assinaturas XML:

Estrutura Básica da Assinatura XML

Uma Assinatura XML consiste em elementos essenciais, conforme mostrado:

<Signature>
<SignedInfo>
<CanonicalizationMethod />
<SignatureMethod />
<Reference>
<Transforms />
<DigestMethod />
<DigestValue />
</Reference>
...
</SignedInfo>
<SignatureValue />
<KeyInfo />
<Object />
</Signature>

Cada elemento Reference significa um recurso específico sendo assinado, identificável pelo atributo URI.

Tipos de Assinaturas XML

1. Assinatura Envelopada: Este tipo de assinatura é um descendente do recurso que assina, significando que a assinatura está contida dentro da mesma estrutura XML que o conteúdo assinado.

Exemplo:

<samlp:Response ... ID="..." ... >
...
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>
...
</samlp:Response>

Em uma assinatura envelopada, o elemento ds:Transform especifica que está envelopada através do algoritmo enveloped-signature.

2. Assinatura Envelopadora: Contrastando com assinaturas envelopadas, assinaturas envelopadoras envolvem o recurso sendo assinado.

Exemplo:

<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
<samlp:Response ... ID="..." ... >
...
</samlp:Response>
</ds:Signature>

3. Assinatura Destacada: Este tipo é separado do conteúdo que assina. A assinatura e o conteúdo existem de forma independente, mas uma ligação entre os dois é mantida.

Exemplo:

<samlp:Response ... ID="..." ... >
...
</samlp:Response>
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>

Em conclusão, Assinaturas XML fornecem maneiras flexíveis de proteger documentos XML, com cada tipo atendendo a diferentes necessidades estruturais e de segurança.

Referências

• https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/