547. SAML 2.0 (Security Assertion Markup Language) - B2B 환경 SSO 구현, XML 기반

핵심 인사이트 (3줄 요약)

본질: SAML 2.0은 인터넷 환경에서 서로 다른 도메인을 가진 기업 간(B2B)에 사용자의 인증(신원)과 인가(권한) 정보를 담은 **XML 기반의 보증서(Assertion)**를 주고받아 **SSO (Single Sign-On)**를 구현하는 OASIS 표준 프레임워크다.

가치: 대기업 직원이 사내 로그인(Active Directory) 한 번만으로 외부에 있는 Salesforce, Google Workspace, Zoom 등 수십 개의 클라우드(SaaS) 업무 앱에 패스워드 없이 자동 접속할 수 있게 하여, 기업의 계정 관리 통제력을 극대화한다.

융합: 거대하고 무거운 XML 구조 탓에 모바일/B2C 환경에서는 OAuth/OIDC 연합에 자리를 내주었지만, 기업용 인프라(엔터프라이즈) 환경에서는 높은 성숙도와 강력한 암호화(XML Signature), 세밀한 정책 설정 능력을 통해 여전히 대체 불가능한 B2B 연동의 황제로 융합 유지되고 있다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: SAML (Security Assertion Markup Language)은 인증/인가 정보를 주고받기 위해 마크업 언어(XML)로 작성된 "보증서(Assertion)"를 정의하는 규격이다. 사용자(Principal), 인증 제공자(IdP, Identity Provider), 서비스 제공자(SP, Service Provider) 3자 간의 신뢰 교환을 규정한다. 2005년 제정된 SAML 2.0이 사실상의 절대 표준이다.
필요성: 기업이 클라우드(SaaS)로 전환하면서 직원들이 각기 다른 외부 서비스 10여 개를 사용하게 되었다. 직원마다 Salesforce 패스워드, Zoom 패스워드를 따로 만들면, 퇴사자 발생 시 10개 사이트에 일일이 들어가 계정을 끊어야 하는 보안 사각지대가 발생한다. "우리 회사 중앙 서버(AD/LDAP)에서 이 사람이 정직원임을 보증해 줄 테니, 외부 SaaS 서비스들은 로그인 창 띄우지 말고 그냥 믿고 들여보내라"는 강력한 B2B 간의 신뢰 교환 언어가 필요했다.
등장 배경: ① 도메인이 다른 웹사이트 간의 쿠키 공유 불가(Cross-Domain 제약) → ② 기업별로 파편화된 외부 솔루션 로그인 지옥 발생 → ③ 이종 도메인 간에도 디지털 서명된 XML 문서를 브라우저(HTTP POST/Redirect)를 통해 배달시켜 신뢰를 구축하는 SAML 2.0의 정립.

┌─────────────────────────────────────────────────────────────┐
│             SAML 도입 전후의 엔터프라이즈 로그인 아키텍처 비교     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   [과거: 사일로(Silo) 클라우드 환경 - 관리 지옥]                      │
│   직원 ──▶ [Salesforce] (ID/PW 개별 생성 및 기억)               │
│   직원 ──▶ [Google WS]  (ID/PW 개별 생성 및 기억)               │
│   * 퇴사 시 중앙 통제 불가능. 비밀번호 포스트잇 노출 등 보안 붕괴.           │
│                                                             │
│   [혁신: SAML 기반 SSO 통합 환경 - 연합(Federation) 구축]           │
│                           (SAML XML 보증서 들고 옴)           │
│   직원 ──(사내 AD 로그인)──▶ [ 사내 통합 인증서버 (IdP) ]         │
│                                │                            │
│                                ├──▶ (SAML 통과) ─▶ [Salesforce (SP)]│
│                                └──▶ (SAML 통과) ─▶ [Google WS  (SP)]│
│   * 사용자는 오직 회사 로그인 창 하나만 봄. 퇴사 시 사내 DB 하나만 잠그면 끝.│
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 그림은 기업 보안 관리자에게 SAML이 왜 구원자와 같은지 보여준다. 클라우드 서비스(SP, Service Provider)들은 자체적인 로그인 로직을 포기하고, 고객사(IdP, Identity Provider)의 결정을 전적으로 신뢰하도록 묶인다. 사용자가 외부 서비스에 접근하려 하면 SP는 로그인 창을 띄우는 대신 사내 IdP로 사용자를 튕겨버린다(Redirect). 사내망에서 인증을 마친 사용자는 IdP가 암호학적 도장을 찍은 XML 보증서(Assertion)를 들고 다시 외부 서비스로 간다. 외부 서비스는 그 도장이 진짜인지 확인하고 즉시 문을 열어준다.

📢 섹션 요약 비유: 한국 국민(사용자)이 외국(SP)에 갈 때마다 그 나라의 신분증을 새로 만들 필요 없이, 대한민국 정부(IdP)가 발행하고 도장을 찍은 여권(SAML XML 보증서) 하나만 들고 가면 전 세계 어느 나라 입국 심사대든 무사히 통과(SSO)시켜 주는 글로벌 외교 조약과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

구성 요소 (SAML 3대 주체 및 Assertion)

요소명	약자 및 의미	역할 및 동작	비유
사용자	Principal / User	사내 시스템에 로그인하고 외부 SaaS를 이용하려는 주체	여행을 떠나는 국민
인증 제공자	IdP (Identity Provider)	사용자의 패스워드를 실제로 검증하고 "이 사람 맞다"는 SAML 보증서를 발급하는 주체 (예: Okta, Azure AD, Ping Identity)	여권 발급 관공서
서비스 제공자	SP (Service Provider)	보증서를 확인한 뒤 실제 서비스를 제공하는 외부 클라우드 시스템 (예: Slack, Zoom, AWS)	입국 심사대
어설션	Assertion (보증서)	"이름: 홍길동, 이메일: hong@..., 부서: 영업" 등의 속성과 IdP의 디지털 서명이 담긴 묵직한 XML 문서	여권 본체 (홀로그램 도장 포함)

SP-Initiated SSO 댄스 (서비스 제공자 주도 로그인 흐름)

SAML 로그인에는 사용자가 포털에서 아이콘을 누르고 출발하는 IdP-Initiated 방식과, 사용자가 서비스 URL을 쳤다가 IdP로 튕기는 SP-Initiated 방식이 있다. 가장 대중적인 SP-Initiated SSO 흐름을 해부한다.

┌───────────────────────────────────────────────────────────────┐
│               SAML 2.0 SP-Initiated SSO 통신 흐름도              │
├───────────────────────────────────────────────────────────────┤
│                                                               │
│   [웹 브라우저 (User)]        [Salesforce (SP)]        [Okta (IdP)] │
│           │                          │                      │     │
│           │ ① salesforce.com 접속      │                      │     │
│           ├─────────────────────────▶│                      │     │
│           │                          │ ② SAML AuthnRequest  │     │
│           │ ③ IdP로 Redirect (302)     │ (로그인 안 했네? IdP로 가라)│    │
│           │◀─────────────────────────┤                      │     │
│           │                          │                      │     │
│           │ ④ Okta 로그인 창에 ID/PW 입력│                      │     │
│           ├──────────────────────────────────────────────────▶│     │
│           │                          │                      │     │
│           │ ⑤ SAML Assertion (XML) 발급 후 SP로 POST 전송 지시 │     │
│           │◀──────────────────────────────────────────────────┤     │
│           │                          │                      │     │
│           │ ⑥ 암호화된 XML 보증서 제출 (HTTP POST) │                      │     │
│           ├─────────────────────────▶│                      │     │
│           │                          │ ⑦ XML 디지털 서명 검증  │     │
│           │                          │                      │     │
│           │ ⑧ "인증 완료, 서비스 이용 시작!"│                      │     │
│           │◀─────────────────────────┤                      │     │
└───────────────────────────────────────────────────────────────┘

[다이어그램 해설] 클라이언트(브라우저)가 서비스(SP)에 접속하면(①), SP는 "나는 널 모른다. 너희 회사 IdP한테 가서 증명서 떼어와"라며 AuthnRequest를 브라우저를 통해 IdP로 리다이렉트시킨다(②, ③). 사용자는 사내 IdP 로그인 화면에서 회사 비밀번호를 입력한다(④). IdP는 인증 성공 후 사용자의 브라우저에게 "이 무거운 XML 문서(Assertion)를 들고 다시 SP로 가서 제출해"라고 지시한다(⑤). 브라우저가 HTTP POST를 통해 SP에게 이 XML을 넘기면(⑥), SP는 사전에 IdP와 맺어둔 공개키 신뢰 관계(Trust)를 통해 XML에 찍힌 서명이 진짜인지 검증(⑦)한 후 서비스를 개방(⑧)한다. 핵심은 IdP와 SP가 백그라운드 서버 간 통신을 직접 하지 않고, 모든 XML 무더기를 '사용자의 웹 브라우저'를 배달부(Front-channel)로 써서 주고받는다는 점이다.

📢 섹션 요약 비유: 회사원이 타사 빌딩(SP)에 들어가려 하니 경비원이 "당신네 회사 보안팀장(IdP)한테 가서 통행증 받아와"라고 돌려보냅니다. 회사로 돌아가 사원증을 찍고 도장이 쾅 찍힌 종이 통행증(Assertion)을 받아와서 다시 경비원에게 제출하니 그제야 문을 열어주는 과정입니다.

Ⅲ. 융합 비교 및 다각도 분석

SAML 2.0 vs OAuth 2.0 / OpenID Connect (OIDC) 심층 비교

"우리 회사 앱에 구글 로그인을 붙일 건데 SAML을 쓸까 OAuth를 쓸까?"는 가장 흔하게 발생하는 아키텍처 혼동이다.

비교 기준	SAML 2.0 (엔터프라이즈 B2B)	OpenID Connect (최신 B2C/웹)	OAuth 2.0 (인가 전용)
데이터 포맷	XML (매우 방대하고 무거움, 파싱 어려움)	JSON / JWT (매우 가볍고 최신 웹 친화적)	JSON (Access Token 전달)
핵심 목적	기업 내부 직원의 타사 서비스 SSO (인증 통합)	일반 소비자의 모바일/웹 소셜 로그인 (신원 증명)	특정 서비스의 권한 위임 (API 호출)
보안 메커니즘	XML 전체 또는 특정 태그(Attribute)를 비대칭키로 강력히 전자 서명 및 암호화	JWT 자체의 짧고 간결한 서명(JWS) 검증	토큰을 TLS 파이프라인으로 보호
환경 적합성	Active Directory 연동, 거대 B2B, 레거시 엔터프라이즈 웹 기반	모바일 앱(iOS/Android), SPA(React, Vue), 마이크로서비스	모바일 앱, SPA, 서버 대 서버 API
단점	모바일 앱에 구현하기 극도로 복잡함, 낡은 기술 취급	구형 레거시 온프레미스 장비(구형 VPN 등)에서는 미지원	사용자 인증(신원 확인) 기능이 없음

SAML은 2005년에 만들어진 중후장대한 장갑차다. 회사 직원의 직급, 소속, 휴대폰 번호 등 엄청나게 긴 속성(Attribute)들을 세밀하게 XML에 담아 완벽하게 서명해서 보낸다. 반면 OIDC는 JSON이라는 스포츠카를 타고 스마트폰 앱과 최신 웹을 씽씽 날아다니는 현대의 표준이다. 모바일 앱(B2C)을 만든다면 무조건 OIDC를, 회사의 낡은 내부 인프라(B2B)를 클라우드 서비스(Salesforce 등)와 묶어야 한다면 SAML을 선택하는 것이 정답이다.

┌───────────────────────────────────────────────────────────────┐
│               SAML의 무거운 XML 덩어리 구조 (Assertion)             │
├───────────────────────────────────────────────────────────────┤
│   <saml:Assertion ID="12345" IssueInstant="2026-04-05T...Z">  │
│     <saml:Issuer>https://idp.mycompany.com</saml:Issuer>      │
│     <ds:Signature> ... (방대한 디지털 서명 암호문) ... </ds:Signature> │
│     <saml:Subject>                                            │
│       <saml:NameID>hong@mycompany.com</saml:NameID>           │
│     </saml:Subject>                                           │
│     <saml:AttributeStatement>                                 │
│       <saml:Attribute Name="Department">                      │
│         <saml:AttributeValue>Engineering</saml:AttributeValue>│
│       </saml:Attribute>                                       │
│     </saml:AttributeStatement>                                │
│   </saml:Assertion>                                           │
│   => 이 길고 무거운 텍스트가 브라우저의 HTTP POST body에 실려 날아간다!  │
└───────────────────────────────────────────────────────────────┘

[다이어그램 해설] SAML의 페이로드(XML)는 기계가 읽기에는 태그가 너무 많고(Overhead), 모바일 앱에서 다루기엔 라이브러리가 무겁다. 이 무거운 XML을 브라우저가 넘겨주려면 HTTP Redirect(URL 길이 제한 존재)로는 불가능하여, 자바스크립트를 이용해 보이지 않는 폼(Form)을 만들어 강제로 HTTP POST를 날리는 변태적인 우회 기법을 쓴다. 그럼에도 불구하고, 저 무거운 XML 안에 서명(ds:Signature)을 태그 단위로 아주 쪼개서 넣을 수 있는 정교한 보안성 덕분에 보수적인 기업/금융 환경에서는 가장 믿음직한 교환 언어로 생명력을 이어가고 있다.

📢 섹션 요약 비유: SAML은 두꺼운 서류철에 공증인 도장을 수십 군데 찍어서 주고받는 보수적인 '관공서 서류(XML)' 규격이고, 최신 OIDC는 스마트폰에 큐알코드(JSON) 하나 띡 띄워서 찍고 통과하는 빠르고 힙한 '모바일 신분증'입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오: 메타데이터 연동 (Federation Trust) 파기 및 인증서 만료 장애

상황: 월요일 아침 9시, 회사의 전 직원이 사내 포털에서 외부 메신저(Slack) 및 메일(Google Workspace)로 접속하려는데 "SAML Invalid Signature" 에러가 뜨며 전사 업무가 100% 마비되었다.
원인: SAML 환경에서 IdP(사내 서버)와 SP(외부 클라우드)는 서로를 믿기 위해 사전에 '메타데이터(Metadata) 파일'을 교환한다. 이 파일 안에는 서로의 URL 주소와 암호화를 위한 **공개키 인증서(X.509)**가 들어 있다. 사내 IdP 보안 인증서의 1년 유효기간이 일요일 자정에 만료되었으나, 외부 SP 쪽에 이 사실을 동기화(업데이트)해주지 않아 SP가 "만료된 도장으로 찍힌 XML은 안 믿어!"라고 거부한 것이다.
의사결정 및 긴급 조치:
- 아키텍트는 사내 IdP(예: Okta 또는 ADFS)에서 서명용 인증서를 갱신 재발급(Rollover)한다.
- 새 인증서가 포함된 메타데이터 XML 파일을 다운로드받아 Salesforce, Slack, Google 등의 관리자 콘솔에 각각 수동 또는 자동(API)으로 덮어씌워 신뢰 관계(Trust Relationship)를 복구한다.
- 재발 방지 대책: SAML 인증서 유효기간을 NMS/SIEM에서 모니터링하여 만료 30일 전에 경보(Alert)를 발송하도록 체계를 구축한다.

도입 체크리스트 및 안티패턴

Just-In-Time (JIT) 프로비저닝: SAML은 인증만 하는 것이 아니다. 외부 SP(예: AWS)에 그 직원의 계정이 아예 없더라도, SAML XML 안에 담긴 Attribute(이름, 직급)를 읽고 SP가 그 즉시 빈 계정을 동적으로 만들어내는 JIT 기능을 지원한다. 이를 켜두지 않으면 관리자가 SP 사이트에 미리 가서 수동으로 빈 계정을 파두어야 하는 행정 낭비가 발생한다.
안티패턴 (SAML 스니핑 간과): "어차피 XML 내부에 디지털 서명이 있으니까 HTTP로 보내도 안전하겠지"라고 착각하는 행위. XML 본문이 탈취되면, 해커는 그 XML을 저장해 두었다가 나중에 다시 SP로 쏘는 재전송 공격(Replay Attack, 탈취한 토큰 재사용)이나 중간자 정보 유출을 시도할 수 있다. SAML 통신을 태우는 웹 채널은 **반드시 100% 종단 간 HTTPS(TLS)**로 암호화되어야 한다.
📢 섹션 요약 비유: SAML 동맹은 두 나라가 "앞으로 1년간 유효한 이 인감도장만 믿자"고 약속한 조약(메타데이터)입니다. 기한이 지나 새 도장을 파놓고 상대국에 알려주지 않으면, 아무리 진짜 국민이 여권을 들고 가도 가짜 취급을 받으며 입국(SSO)을 거절당하는 엄청난 혼란이 옵니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	서비스별 개별 로그인 (Silo)	SAML 2.0 연합(Federation) 로그인	개선 효과
정량 (생산성)	하루 5개 솔루션에 5번 패스워드 타이핑 (분실/초기화 시 시간 낭비 심각)	아침에 PC 켜고 한 번만 치면 5개 솔루션 프리패스 (SSO)	임직원 연간 비밀번호 찾기/재설정 업무 소요 시간 수천 시간 절약
정량 (보안 관리)	퇴사 시 10개 클라우드 계정 수동 비활성화 누락 발생률 15%	사내 AD 비활성화 시 모든 클라우드 접속 즉각 차단	퇴사자 휴면 계정을 통한 데이터 유출 위험률 0% 원천 차단
정성 (컴플라이언스)	SaaS 업체가 자사 DB에 우리 직원 패스워드 원본을 저장하여 찜찜함	패스워드는 우리 회사 서버만 알고, 외부엔 '합격 도장(XML)'만 줌	중앙 집중형 제로 트러스트 통제권 및 100% 감사 가시성 획득

미래 전망 및 진화 방향

OIDC (OpenID Connect)로의 서서히 진행되는 교체: 15년간 B2B 엔터프라이즈의 제왕이었던 SAML은 너무 복잡하고 방대한 스펙 때문에 개발자들의 원성을 사 왔다. 새로운 B2B SaaS 앱들은 이제 무거운 XML 파서 대신, JSON 기반의 빠르고 가벼운 OIDC를 엔터프라이즈 SSO의 기본 옵션으로 채택하며 패러다임이 조심스럽게 넘어가고 있다.
IdP 생태계의 팽창 (Identity as a Service): 과거에는 기업이 직접 윈도우 ADFS(Active Directory Federation Services)라는 무거운 SAML 서버를 사내망에 돌렸다. 지금은 Okta, Ping Identity, Microsoft Entra ID 같은 클라우드 아이덴티티 서비스(IDaaS)가 회사의 SAML 중추 역할을 클라우드 위로 통째로 올려, 전 세계 지사와 SaaS들을 묶어내는 글로벌 Identity 허브로 진화했다.

참고 표준

OASIS SAML V2.0: 2005년 제정된 코어 아키텍처, 프로토콜, 바인딩(브라우저를 어떻게 탈 것인가)에 관한 거대한 스펙 문서의 집합.
SAML 2.0 Web Browser SSO Profile: 우리가 아는 "웹 브라우저를 통한 통합 로그인"을 규정한 가장 핵심적이고 대중적인 SAML의 사용처 표준.

수많은 클라우드 파편들이 등장하며 쪼개진 기업의 통제권을 하나로 강력하게 묶어준 접착제가 바로 SAML이다. 비록 기술적으로 무겁고 시대착오적인 XML 냄새가 날지언정, 그 견고한 보안 신뢰 사슬(Trust Chain)과 완벽한 B2B 연동 철학은 현대 인터넷 경제(SaaS)가 융성할 수 있었던 가장 든든한 반석으로 기억될 것이다.

📢 섹션 요약 비유: 수백 개의 다른 언어를 쓰는 나라(SaaS)들이 모인 거대한 지구촌에서, 깐깐하지만 한 치의 오차도 허용하지 않는 완벽한 공용 외교 언어(SAML)가 있었기에 오늘날 기업들은 안심하고 구글, 줌, 슬랙을 내 집처럼 자유롭게 넘나들 수 있는 것입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
SSO (Single Sign-On)	한 번의 자격 증명으로 다수의 서비스를 이용하게 하는 기술적 목표이며, 엔터프라이즈(B2B) 환경에서 이 목표를 달성하는 가장 압도적인 도구가 SAML이다.
OAuth 2.0 / OIDC	SAML의 거대하고 무거운 XML 문법을 버리고 최신 웹/모바일 친화적인 JSON 포맷으로 대체하기 위해 등장한 현대적 라이벌이자 후계자들이다.
Active Directory / LDAP	SAML의 IdP(인증 제공자)는 껍데기일 뿐, 그 뒤에서 실제로 사용자의 비밀번호가 맞는지 조회하는 거대한 사내 계정 원부(DB) 역할을 수행한다.
Metadata (메타데이터 XML)	IdP와 SP가 서로 암호화/복호화에 쓸 공개키(인증서)와 도착지 URL 정보를 담아 사전에 교환하는, 통신 시작을 위한 절대적인 신뢰의 약속 파일이다.
IdP (Identity Provider) & SP (Service Provider)	신원 보증서를 발행하는 관공서(IdP)와, 그 보증서를 믿고 서비스를 내어주는 가게(SP)라는 SAML 아키텍처의 가장 중요한 양대 산맥이다.

👶 어린이를 위한 3줄 비유 설명

회사원 아빠가 하루에도 수십 개의 다른 회사 웹사이트(메일, 화상회의, 결재)에 들어가야 하는데, 사이트마다 비밀번호를 다르게 만들면 다 외울 수가 없어서 머리가 터져요.
SAML은 아빠네 회사 경비 아저씨(IdP)가 "이 사람은 우리 회사 정직원이 맞다!"라고 쾅 도장을 찍은 특별한 황금 티켓(XML 보증서)을 발급해 주는 마법의 규약이에요.
이 티켓만 딱 들고 다른 사이트들에 찾아가면, 사이트들이 아빠에게 비밀번호를 묻지 않고 티켓 도장만 확인한 뒤 즉시 문을 활짝 열어주는(SSO) 아주 멋진 시스템이랍니다.