SAML Basics
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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 do serviço.
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.
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:
Tentativa de Acesso ao Recurso: O usuário tenta acessar um recurso protegido.
Geração da Solicitação SAML: O SP não reconhece o usuário e gera uma Solicitação SAML.
Redirecionamento para o IdP: O usuário é redirecionado para o IdP, com a Solicitação SAML passando pelo navegador do usuário.
IdP Recebe a Solicitação: O IdP recebe a Solicitação SAML.
Autenticação no IdP: O IdP autentica o usuário.
Validação do Usuário: O IdP valida a legitimidade do usuário para acessar o recurso solicitado.
Criação da Resposta SAML: O IdP gera uma Resposta SAML contendo as afirmações necessárias.
Redirecionamento para a URL ACS do SP: O usuário é redirecionado para a URL do Serviço Consumidor de Afirmações (ACS) do SP.
Validação da Resposta SAML: O ACS valida a Resposta SAML.
Acesso ao Recurso Concedido: O acesso ao recurso inicialmente solicitado é concedido.
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:
A solicitação SAML bruta se parece com isto:
Key elements of this request include:
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.
Following the SAML Request generation, the SP responds with a 302 redirect, directing the browser to the IdP with the SAML Request encoded in the HTTP response's Location header. The RelayState parameter maintains the state information throughout the transaction, ensuring the SP recognizes the initial resource request upon receiving the SAML Response. The SAMLRequest parameter is a compressed and encoded version of the raw XML snippet, utilizing Deflate compression and base64 encoding.
You can find a full SAML response here. The key components of the response include:
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.
Following the SAML Response, the process includes a 302 redirect from the IdP. This leads to a POST request to the Service Provider's Assertion Consumer Service (ACS) URL. The POST request includes RelayState and SAMLResponse parameters. The ACS is responsible for processing and validating the SAML Response.
After the POST request is received and the SAML Response is validated, access is granted to the protected resource initially requested by the user. This is illustrated with a GET request to the /secure/ endpoint and a 200 OK response, indicating successful access to the resource.
XML Signatures are versatile, capable of signing an entire XML tree or specific elements within it. They can be applied to any XML Object, not just Response elements. Below are the key types of XML Signatures:
An XML Signature consists of essential elements as shown:
Cada elemento Reference significa um recurso específico sendo assinado, identificável pelo atributo URI.
Assinatura Envelopada: Este tipo de assinatura é um descendente do recurso que assina, significando que a assinatura está contida na mesma estrutura XML que o conteúdo assinado.
Exemplo:
Em uma assinatura envelopada, o elemento ds:Transform especifica que está envelopada através do algoritmo enveloped-signature.
Assinatura Envelopante: Contrastando com assinaturas envelopadas, assinaturas envelopantes envolvem o recurso sendo assinado.
Exemplo:
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:
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.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
