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)**는 신원 제공자(IdP)가 서비스 제공자(SP)에게 권한 부여 자격 증명을 전송할 수 있도록 하여 단일 로그인(SSO)을 용이하게 합니다. 이 접근 방식은 여러 웹사이트에서 단일 자격 증명을 사용할 수 있도록 하여 여러 로그인 관리를 간소화합니다. IdP와 SP 간의 표준화된 통신을 위해 XML을 활용하여 사용자 신원의 인증과 서비스 권한 부여를 연결합니다.
SAML은 기업이 SSO 로그인 보안을 보다 잘 제어할 수 있도록 설계되었습니다.
OAuth는 모바일 친화적으로 설계되었으며, JSON을 사용하고 Google 및 Twitter와 같은 회사의 협력으로 개발되었습니다.
자세한 내용은 https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/의 전체 게시물을 확인하세요. 다음은 요약입니다:
SAML 인증 프로세스는 여러 단계로 구성되어 있으며, 아래의 도식에서 설명됩니다:
리소스 접근 시도: 사용자가 보호된 리소스에 접근하려고 합니다.
SAML 요청 생성: SP는 사용자를 인식하지 못하고 SAML 요청을 생성합니다.
IdP로 리디렉션: 사용자는 IdP로 리디렉션되며, SAML 요청은 사용자의 브라우저를 통해 전달됩니다.
IdP가 요청 수신: IdP는 SAML 요청을 수신합니다.
IdP에서 인증: IdP는 사용자를 인증합니다.
사용자 검증: IdP는 요청된 리소스에 접근할 수 있는 사용자의 정당성을 검증합니다.
SAML 응답 생성: IdP는 필요한 주장을 포함한 SAML 응답을 생성합니다.
SP의 ACS URL로 리디렉션: 사용자는 SP의 Assertion Consumer Service (ACS) URL로 리디렉션됩니다.
SAML 응답 검증: ACS는 SAML 응답을 검증합니다.
리소스 접근 허용: 처음 요청한 리소스에 대한 접근이 허용됩니다.
사용자가 https://shibdemo-sp1.test.edu/secure/에서 보안 리소스에 접근을 요청하는 시나리오를 고려해 보십시오. SP는 인증이 없음을 인식하고 SAML 요청을 생성합니다:
원시 SAML 요청은 다음과 같습니다:
Key elements of this request include:
AssertionConsumerServiceURL: IdP가 인증 후 SAML 응답을 보낼 위치를 지정합니다.
Destination: 요청이 전송되는 IdP의 주소입니다.
ProtocolBinding: SAML 프로토콜 메시지의 전송 방법을 정의합니다.
saml:Issuer: 요청을 시작한 엔티티를 식별합니다.
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: 이 섹션은 XML 서명으로, assertion의 발행자의 무결성과 진위를 보장합니다. 예제의 SAML 응답에는 메시지용과 assertion용 두 개의 ds:Signature 요소가 포함되어 있습니다.
saml:Assertion: 이 부분은 사용자의 신원 및 기타 속성에 대한 정보를 포함합니다.
saml:Subject: assertion의 모든 진술의 주요 주체를 지정합니다.
saml:StatusCode: 해당 요청에 대한 작업의 상태를 나타냅니다.
saml:Conditions: Assertion의 유효성 타이밍 및 지정된 서비스 제공자와 같은 조건을 자세히 설명합니다.
saml:AuthnStatement: IdP가 Assertion의 주체를 인증했음을 확인합니다.
saml:AttributeStatement: Assertion의 주체를 설명하는 속성을 포함합니다.
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:
각 Reference 요소는 URI 속성으로 식별 가능한 서명된 특정 리소스를 나타냅니다.
Enveloped Signature: 이 유형의 서명은 서명하는 리소스의 자손으로, 서명이 서명된 콘텐츠와 동일한 XML 구조 내에 포함되어 있습니다.
예시:
enveloped 서명에서 ds:Transform 요소는 enveloped-signature 알고리즘을 통해 enveloped되었음을 지정합니다.
Enveloping Signature: enveloped 서명과 대조적으로, enveloping 서명은 서명되는 리소스를 감쌉니다.
예시:
Detached Signature: 이 유형은 서명하는 콘텐츠와 분리되어 있습니다. 서명과 콘텐츠는 독립적으로 존재하지만, 두 사이의 링크는 유지됩니다.
예시:
결론적으로, XML 서명은 XML 문서를 보호하는 유연한 방법을 제공하며, 각 유형은 서로 다른 구조적 및 보안 요구를 충족합니다.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
