SAML 바인딩 — HTTP Redirect와 POST

SAML 프로토콜 메시지는 그 자체로만 존재하는 게 아니라, 어떤 방식으로 HTTP 위에 실어 보낼지가 정해져야 전달돼요. 이 '실어 보내는 규칙'을 **바인딩(Binding)**이라고 해요. 그중 실무에서 가장 자주 만나는 두 가지가 HTTP Redirect 바인딩과 HTTP POST 바인딩인데, 둘은 메시지를 브라우저를 통해 옮긴다는 점은 같아도 "URL에 담느냐, HTML 폼에 담느냐"에서 갈려요.

출처: Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0

본문

바인딩은 SAML 요청-응답 메시지 교환을 표준 메시징·통신 프로토콜에 사상(mapping)한 것이에요. 각 바인딩은 XML 메시지를 들고 가는 운반 방식과 메시지 무결성·기밀성 보호 수단, 그리고 원래 요청과 응답을 이어주는 RelayState 메커니즘을 함께 정의해요.

HTTP Redirect 바인딩

Redirect 바인딩은 메시지를 HTTP 302 리다이렉트의 URL 쿼리 파라미터로 전달해요. 메시지가 여러 줄이고 길어질 수 있어서 DEFLATE로 압축한 뒤 base64로 인코딩해서 URL에 실어요. 쿼리 파라미터로는 요청이면 SAMLRequest, 응답이면 SAMLResponse, 그리고 원래 요청과의 연관을 위한 RelayState를 쓸 수 있어요.

https://idp.example.com/sso?
  SAMLRequest=<base64(DEFLATE(<AuthnRequest/>))>
  &RelayState=<원래 요청 연관 값>

URL 길이 제한 때문에 Redirect는 보통 짧은 요청 메시지(<AuthnRequest> 등)에 적합해요. 긴 어써션이 담긴 응답을 Redirect로 보내면 URL 한계를 넘기 쉬워서, 브라우저 SSO 프로필은 응답에 Redirect를 쓰지 말라고 명시해요. 메시지에 서명이 필요하면 SigAlg와 Signature 파라미터를 함께 붙여서 요청 발신자를 검증 가능하게 만들어요.

HTTP POST 바인딩

POST 바인딩은 메시지를 **HTML 폼의 숨김 필드(hidden input)**에 실어 보내요. XML 메시지를 base64로 인코딩해서 SAMLRequest 또는 SAMLResponse 라는 이름의 숨김 필드에 넣고, RelayState도 같은 방식으로 실어요.

<form method="post" action="https://sp.example.com/acs">
  <input type="hidden" name="SAMLResponse" value="<base64 인코딩된 <Response>/>"/>
  <input type="hidden" name="RelayState" value="..."/>
  <input type="submit" value="계속"/>
</form>

이 폼은 브라우저가 자동 제출하도록 만들어져서, 사용자는 화면을 거의 보지 못해요. 응답처럼 크고 자세한 메시지를 전달하기에 적합한 방식이에요. 브라우저 SSO 플로에서 IdP→SP로 가는 <Response>가 전형적으로 POST 바인딩을 쓰는 이유이기도 해요.

Redirect vs POST 언제 무엇을?

Redirect: 요청(<AuthnRequest>, <LogoutRequest>)처럼 짧고 브라우저가 GET으로 이동하기 쉬운 흐름에 잘 어울려요.
POST: 응답(<Response>, <LogoutResponse>)처럼 길고 어써션을 실어야 하는 경우에 어울려요.

선택의 기준은 항상 "메시지가 URL에 실리기 너무 크지 않은가"예요. 어써션이 포함된 긴 응답은 POST가 안전하지요.

더 알아보기

SAML 브라우저 SSO 플로 — Redirect·POST 바인딩이 실제로 쓰이는 인증 흐름.
SAML 어써션 — 바인딩이 운반하는 핵심 메시지인 <Assertion>.
SAML 메타데이터 — 각 끝점이 어떤 바인딩을 지원하는지 선언하는 문서.