SAML 브라우저 SSO 플로

SAML 브라우저 SSO 플로 (Web Browser SSO)

SSO(Single Sign-On)가 실제로 어떻게 동작하는지 한 가지 플로로 설명해 줄 수 있는 게 바로 **웹 브라우저 SSO 프로필(Web Browser SSO Profile)**이에요. 사용자가 SP(서비스 제공자)의 보호된 리소스를 요청하면, SP는 사용자 브라우저를 IdP(신원 공급자)로 돌려보내고, 인증된 사용자라는 결과를 담은 <Response>를 다시 받아 접근을 허가하는 흐름이지요. 여기서 주고받는 두 끝점, Single Sign-On Service와 Assertion Consumer Service의 이름을 기억해 두면 플로가 한눈에 들어와요.

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

본문

두 끝점부터 잡고 가요

Single Sign-On Service — IdP 쪽에 있는 인증 요청 프로토콜 끝점이에요. 사용자 브라우저가 <AuthnRequest>(또는 그것을 나타내는 artifact)를 여기로 전달받아요.
Assertion Consumer Service — SP 쪽에 있는 끝점이에요. <Response> 메시지(또는 artifact)가 브라우저를 거쳐 여기로 도착해요.

여섯 단계의 흐름

HTTP 요청 to SP: 사용자(User Agent)가 SP의 보호된 리소스를 아직 보안 컨텍스트 없이 요청해요.
SP가 IdP 결정: SP는 자신이 선호하는 바인딩을 지원하는 IdP의 끝점 위치를 구해요. 방법은 구현에 따라 다르고, SAML IdP 디스커버리 프로필을 쓸 수도 있어요.
SP → IdP로 <AuthnRequest> 발행: SP는 사용자 브라우저가 IdP로 전달할 <AuthnRequest> 메시지를 만들어요. 이 메시지 전달에는 HTTP Redirect, HTTP POST, HTTP Artifact 바인딩을 쓸 수 있어요.
IdP가 사용자 식별: IdP가 그 사람이 누구인지 식별해요. 새로 인증을 요구할 수도 있고, 이미 맺어진 인증 세션을 재사용할 수도 있어요.
IdP → SP로 <Response> 발행: IdP는 사용자 브라우저가 SP로 전달할 <Response> 메시지를 내보내요. 이때 HTTP POST 또는 HTTP Artifact 바인딩을 사용하고, 메시지에는 (최소한) 인증 어써션이 들어가요. HTTP Redirect는 응답이 대부분 사용자 에이전트의 URL 길이 한계를 넘어서므로 MUST NOT 사용해요.
SP가 접근 허용/거부: SP는 받은 응답에 따라 사용자에게 자기 오류를 돌려주거나, 보안 컨텍스트를 세우고 요청한 리소스를 돌려줘요.

그림으로 보면

User Agent           Identity Provider          Service Provider
   |                         |                         |
   |  1. 보호된 리소스 요청    |                         |
   |-------------------------->                         |
   |                         |    2. IdP 결정 (방법 다양) |
   |                         |<------------------------|
   |  3. <AuthnRequest> 발행 |                         |
   |<------------------------>|                         |
   |  4. IdP가 사용자 식별     |                         |
   |  (방법은 프로필 밖)       |                         |
   |  5. <Response> 발행       |                         |
   |------------------------->|                         |
   |  6. 접근 허용/거부 결정   |                         |
   |<-------------------------|                         |

`ForceAuthn`과 `IsPassive`

<AuthnRequest>의 ForceAuthn 속성이 true면 IdP는 기존 세션에 기대지 않고 새로 사용자 신원을 확인하도록 강제돼요. 반대로 IsPassive가 있으면 IdP가 사용자를 실제 로그인 화면에 끌어들이지 못하게 돼요. 이 두 속성은 "얼마나 강하게, 얼마나 조용히 인증할지"를 조절한다고 볼 수 있어요.

RelayState

SP가 원래 요청과 그 뒤의 상호작용을 이어주고 싶을 때, 각 바인딩이 제공하는 RelayState 메커니즘을 쓸 수 있어요. SP는 보안이 필요하지 않은 경우 외에는 RelayState 값에 원래 요청 내용을 되도록 조금만 노출하도록 해요.

더 알아보기

SAML 싱글 로그아웃 플로 — SSO로 시작된 세션을 한 번에 끝내는 흐름.
SAML 어써션 — <Response>가 운반하는 인증 어써션의 구조.
SAML 바인딩 — <AuthnRequest>/<Response>를 HTTP로 옮기는 Redirect·POST 방식.
SAML 메타데이터 — 두 끝점과 바인딩 지원을 기술하는 엔티티 문서.

SAML 브라우저 SSO 플로