SAML 2.0 기반 통합인증(SSO)과 아이덴티티 페더레이션

1. 개요

가. 정의 및 등장 배경

SAML(Security Assertion Markup Language)은 서로 다른 보안 도메인 사이에서 인증·인가·속성 정보를 XML 기반의 표준화된 단언(Assertion)으로 안전하게 교환하기 위한 OASIS 표준이며, 특히 SAML 2.0은 웹 브라우저를 매개로 한 통합인증(SSO, Single Sign-On)과 아이덴티티 페더레이션(Identity Federation)의 사실상 기업 표준으로 자리 잡았다. 요약하면 SAML은 "사용자가 누구이고(인증), 무엇을 할 수 있는가(인가·속성)"를 아이덴티티 공급자(IdP)가 선언하면 서비스 공급자(SP)가 그 선언을 신뢰하여 로그인을 대체하는 신뢰 전달 프로토콜이다.

SAML이 등장한 근본 배경은 '애플리케이션마다 따로 로그인하는 구조는 확장 불가능하다'는 인식에 있다. 조직이 쓰는 SaaS·내부 시스템이 수십~수백 개로 늘어나면, 각 애플리케이션이 저마다 사용자 계정과 비밀번호를 별도로 보관하게 된다. 이는 사용자에게는 반복 로그인과 비밀번호 피로(password fatigue)를, 관리자에게는 입·퇴사자의 계정을 시스템마다 일일이 생성·삭제해야 하는 계정 수명주기(provisioning/deprovisioning) 부담을, 보안 측면에서는 비밀번호가 여러 곳에 흩어져 공격 표면(attack surface)이 선형적으로 증가하는 문제를 낳는다. SAML은 인증의 책임을 단 하나의 신뢰 지점(IdP)으로 집중시키고, 나머지 애플리케이션은 그 결과를 넘겨받기만 하게 함으로써 이 문제를 구조적으로 해소한다.

역사적으로 SAML 1.0/1.1은 2002~2003년에, 현재까지 쓰이는 SAML 2.0은 2005년 OASIS에서 표준화되었다. 당시 경쟁 규격이던 Liberty Alliance의 ID-FF와 Shibboleth의 요소를 수렴하여 하나로 통합한 결과물이 2.0이며, 이 때문에 SAML 2.0은 이전 버전과 하위 호환되지 않는다. 20년 가까이 지난 지금도 대학 연합(eduGAIN/InCommon), 정부·금융의 B2B 포털, 대형 SaaS(예: Microsoft 365, Salesforce, Google Workspace)의 기업 SSO 연동에서 여전히 핵심적으로 사용된다. 한편 모바일·API·네이티브 앱 시대에는 경량 JSON 기반의 [[oauth2-oidc]]가 부상했으나, SAML은 브라우저 기반 엔터프라이즈 웹 SSO 영역에서 여전히 대체 불가능한 위상을 유지한다.

나. 필요성

SAML의 필요성은 사용자·관리자·보안의 세 관점에서 모두 설명된다. 사용자 관점에서는 한 번의 인증으로 연합된 모든 서비스에 재로그인 없이 접근하여 생산성이 올라간다. 관리자 관점에서는 계정·권한을 IdP 한 곳에서 중앙집중적으로 통제하므로, 퇴사자가 발생하면 IdP 계정 하나만 비활성화해도 연동된 모든 SP 접근이 즉시 차단된다. 이는 '유령 계정'으로 인한 사고를 원천 차단하는 강력한 통제 수단이다.

보안 관점의 필요성이 특히 중요하다. SAML 연동에서는 사용자의 비밀번호가 SP(서비스)로 전달되지 않는다. 사용자는 오직 IdP에만 자격증명을 제시하고, SP는 IdP가 서명한 단언만 받는다. 따라서 수십 개 SaaS에 비밀번호가 흩어져 저장되는 위험이 사라지고, 다중 인증(MFA)·위험 기반 인증 같은 강화 정책도 IdP 한 곳에만 적용하면 전사적으로 일관되게 강제된다. 국내에서도 전자정부 서비스 연계, 금융권의 그룹사 통합포털에서 이러한 중앙 인증 통제가 컴플라이언스(ISMS-P의 접근통제 요구) 충족의 기반이 된다.

다. 핵심 특징

SAML의 특징은 세 가지로 압축된다. 첫째는 XML 기반 단언과 디지털 서명으로, 모든 메시지는 XML 문서이며 XML Signature(XML-DSig)로 위·변조를 방지하고 필요 시 XML Encryption으로 기밀성을 더한다. 둘째는 브라우저 리다이렉트 중심의 프런트채널 프로토콜로, 별도 클라이언트 없이 표준 웹 브라우저의 리다이렉트/폼 POST만으로 도메인 간 신뢰를 전달한다. 셋째는 메타데이터 기반 신뢰 사전설정으로, IdP와 SP는 서로의 엔드포인트·인증서를 담은 XML 메타데이터를 사전에 교환하여 신뢰 관계를 정적으로 구축한다. 이 세 특징이 결합해 SAML은 '설정으로 신뢰를 고정하고, 서명으로 무결성을 보장하는' 성숙하고 보수적인 엔터프라이즈 프로토콜로 기능한다.

2. SAML의 전체 구조와 구성요소

SAML은 단일 메시지 규격이 아니라 Assertion(무엇을 말하는가)·Protocol(어떻게 주고받는가)·Binding(어느 전송 계층에 싣는가)·Profile(특정 사용 시나리오 조합)의 네 축으로 이루어진 계층적 프레임워크로 이해해야 한다. 아래는 주요 역할자와 구성요소 간의 신뢰 관계를 나타낸 전체 구조도이다.

flowchart LR
  subgraph USER["사용자 영역"]
    UA["웹 브라우저(User Agent)"]
  end
  subgraph IDPDOM["IdP 보안 도메인"]
    IDP["아이덴티티 공급자(IdP)"]
    DIR["사용자 디렉터리(LDAP/AD)"]
    IDP --- DIR
  end
  subgraph SPDOM["SP 보안 도메인"]
    SP["서비스 공급자(SP)"]
    APP["보호 자원(애플리케이션)"]
    SP --- APP
  end
  UA -->|"① 접근/인증요청"| SP
  SP -->|"② AuthnRequest(서명)"| UA
  UA -->|"③ 자격증명 제시"| IDP
  IDP -->|"④ 서명된 Assertion"| UA
  UA -->|"⑤ Assertion 전달"| SP
  IDP <-.->|"메타데이터·인증서 사전교환(신뢰설정)"| SP

이 구조의 핵심은 IdP와 SP가 사용자를 사이에 두고 직접 통신하지 않고, 브라우저를 '신뢰 전달자'로 삼는다는 점이다. 양측은 사전에 메타데이터(엔드포인트 URL, X.509 공개키 인증서, 지원 바인딩)를 교환해 신뢰를 고정해 두며, 실제 로그인 순간에는 브라우저가 서명된 메시지를 양쪽으로 운반한다. 이렇게 하면 IdP와 SP가 서로 네트워크 경로로 직접 연결되어 있지 않아도 도메인 간 SSO가 성립한다.

가. 핵심 역할자 — IdP, SP, Principal

SAML의 세 주연은 주체(Principal, 보통 최종 사용자), 아이덴티티 공급자(IdP), 서비스 공급자(SP)이다. IdP는 조직의 사용자 디렉터리(Active Directory·LDAP)와 결합되어 사용자를 실제로 인증하고 단언을 발급하는 '신뢰의 원천'이다. SP는 보호 자원을 보유하되 스스로 인증하지 않고 IdP의 단언을 소비하는 '신뢰의 소비자'이다.

이 역할 분리가 SAML의 보안 모델을 규정한다. SP는 비밀번호를 저장하지 않으므로 SP가 침해되어도 사용자 자격증명이 유출되지 않으며, 인증 강화(MFA 적용, 접속 위치 제한)는 IdP에만 집중하면 된다. 반대로 이는 IdP가 전사 보안의 단일 신뢰점(Single Point of Trust)이자 단일 장애점(SPOF)이 됨을 의미한다. IdP가 다운되면 연동된 모든 SP에 신규 로그인이 불가능해지므로, IdP의 고가용성·이중화는 SAML 아키텍처의 최우선 비기능 요구가 된다. 실제 대형 조직은 IdP를 액티브-액티브로 다중화하고 지역 분산 배치하여 가용성을 확보한다.

나. Assertion의 3종 — 인증·속성·인가결정

SAML 단언(Assertion)은 IdP가 주체에 대해 선언하는 '진술문'이며, 담는 내용에 따라 세 종류의 Statement를 포함한다. 각각의 의미와 실무 활용은 다음과 같다.

구분	Statement 종류	담는 정보	실무 활용 예
인증	AuthnStatement	인증 시각·방법(AuthnContext)	"이 사용자는 10:05에 MFA로 인증됨"
속성	AttributeStatement	이메일·부서·역할 등 사용자 속성	부서 속성으로 SP 내 권한 부여
인가결정	AuthzDecisionStatement	특정 자원 접근 허용/거부	(현재는 거의 쓰이지 않음, XACML로 대체)

실무에서 가장 중요한 것은 AuthnStatement와 AttributeStatement이다. AuthnStatement의 AuthnContext는 '어떤 강도로 인증했는가'를 표현하여, SP가 "이 자원은 반드시 MFA로 인증된 세션만 허용"과 같은 단계적 접근통제(step-up authentication)를 구현하게 한다. AttributeStatement는 사용자의 부서·직급·그룹 같은 속성을 전달하여, SP가 별도 사용자 DB 없이도 단언에 실린 속성만으로 역할 기반 접근통제(RBAC)를 수행할 수 있게 한다. 예컨대 '재무팀' 속성을 가진 사용자에게만 회계 모듈을 노출하는 식이다. 이처럼 속성 전달은 단순 로그인을 넘어 '속성 기반 인가'로 확장되는 지점이다.

다. Binding과 Profile — 전송과 시나리오 조합

Binding은 SAML 메시지를 어떤 전송 메커니즘에 실을지를 정의한다. 대표적으로 HTTP-Redirect 바인딩(메시지를 URL 쿼리에 압축·인코딩, 짧은 AuthnRequest에 적합), HTTP-POST 바인딩(메시지를 HTML 폼의 hidden 필드로 자동 submit, 크고 서명된 Assertion 전달에 적합), Artifact 바인딩(브라우저에는 짧은 참조값(artifact)만 전달하고 실제 단언은 IdP-SP가 백채널로 직접 교환)이 있다. Artifact 바인딩은 단언이 브라우저를 거치지 않아 노출 위험이 낮지만, SP와 IdP 간 직접 통신 경로가 필요하다는 제약이 있다.

Profile은 이들 요소를 특정 시나리오에 맞게 조합한 '사용 지침'이다. 가장 널리 쓰이는 것이 Web Browser SSO Profile로, 대부분의 기업 SAML 연동이 이 프로파일을 따른다. 그 밖에 하나의 IdP 로그아웃으로 모든 SP 세션을 종료하는 Single Logout(SLO) Profile, 메타데이터 교환을 표준화한 Metadata Profile 등이 있다. 이처럼 SAML은 네 축의 조합으로 다양한 상황을 포괄하되, 실무에서는 "Web Browser SSO + HTTP-POST 바인딩 + 서명된 Assertion"이 사실상 표준 조합으로 통용된다.

라. 메타데이터와 신뢰 사전설정

SAML이 OIDC의 동적 등록(Dynamic Client Registration)과 결정적으로 다른 지점은, 신뢰 관계를 런타임이 아니라 사전에 메타데이터 교환으로 정적으로 고정한다는 데 있다. IdP와 SP는 각자 자신의 엔티티 ID(EntityID), 엔드포인트 URL(SSO·ACS·SLO), 서명·암호화용 X.509 공개키 인증서, 지원 바인딩 목록을 담은 표준 XML 메타데이터 문서를 발행하고, 연동 상대는 이를 가져와 자신의 설정에 등록한다. 이 교환이 끝나는 순간 두 도메인 사이에는 '서로의 공개키로 서명을 검증할 수 있고, 어느 URL로 메시지를 보내야 하는지 아는' 신뢰 경로가 성립한다.

이러한 정적 신뢰 모델은 장단이 뚜렷하다. 장점은 런타임에 미지의 상대와 신뢰를 협상할 필요가 없어 공격 표면이 작고 예측 가능하다는 것이다. 단점은 인증서가 만료·교체될 때 양측 메타데이터를 함께 갱신하지 않으면 연동이 통째로 끊긴다는 점이며, 실제 SAML 장애의 상당수가 'IdP 서명 인증서 만료'에서 비롯된다. 따라서 대규모 연합(InCommon·eduGAIN 등)은 다수 기관의 메타데이터를 한데 모아 주기적으로 배포하는 메타데이터 집합(aggregate)과 자동 갱신 체계를 운영하며, 개별 연동에서도 인증서 만료 모니터링과 롤오버(rollover) 절차를 운영 표준으로 둔다.

3. SP-Initiated SSO 동작 절차

SAML SSO는 흐름을 누가 시작하느냐에 따라 SP-Initiated(사용자가 먼저 SP에 접근)와 IdP-Initiated(사용자가 IdP 포털에서 앱을 클릭)로 나뉜다. 엔터프라이즈 표준이자 보안상 권장되는 SP-Initiated 흐름을 세부도로 보이면 다음과 같다.

sequenceDiagram
  participant U as 브라우저
  participant S as SP(서비스)
  participant I as IdP(인증서버)
  U->>S: ① 보호 자원 요청(미인증)
  S->>U: ② AuthnRequest 생성·리다이렉트
  U->>I: ③ AuthnRequest 전달
  I->>U: ④ 로그인 폼(미인증 시)
  U->>I: ⑤ 자격증명+MFA 제시
  I->>I: ⑥ 사용자 검증·Assertion 생성·서명
  I->>U: ⑦ HTML Form(POST) + 서명 Assertion
  U->>S: ⑧ Assertion을 ACS로 POST
  S->>S: ⑨ 서명·조건·Audience 검증
  S->>U: ⑩ 세션 수립·자원 제공

절차의 출발점은 ①~② 단계다. 미인증 사용자가 SP의 보호 자원을 요청하면, SP는 AuthnRequest(인증 요청 XML)를 만들어 사용자를 IdP로 리다이렉트한다. 이때 SP는 요청에 서명하여 자신이 정당한 SP임을 증명하고, 나중에 돌아올 응답과 짝을 맞추기 위한 식별자(ID)와 원래 가려던 위치를 담은 RelayState를 함께 보낸다. RelayState는 로그인을 마친 뒤 사용자를 원래 요청한 페이지로 되돌리기 위한 '딥링크 복원' 장치다.

③~⑦ 단계는 IdP의 인증 구간이다. IdP는 사용자가 이미 로그인된 세션이 있으면 재인증 없이 곧바로 단언을 발급하고(이것이 SSO의 핵심 — 두 번째 SP부터는 로그인 화면이 아예 나타나지 않는다), 없으면 로그인 폼을 제시해 자격증명과 MFA를 검증한다. 검증이 끝나면 IdP는 사용자 식별자(NameID)와 속성, 인증 맥락을 담은 Assertion을 생성하고 XML-DSig로 서명한 뒤, HTTP-POST 바인딩에 따라 자동 제출되는 HTML 폼으로 브라우저에 돌려준다.

⑧~⑩ 단계가 SP의 검증 구간이자 보안의 핵심이다. 브라우저는 단언을 SP의 ACS(Assertion Consumer Service) 엔드포인트로 POST하고, SP는 받은 단언을 엄격히 검증한다. 구체적으로 ⓐ IdP의 공개키로 서명을 검증해 위·변조와 발신자 진위를 확인하고, ⓑ NotBefore·NotOnOrAfter로 유효시간을 확인해 만료·재사용을 막고, ⓒ Audience 제한으로 이 단언이 바로 자신(SP)을 위해 발급된 것인지를 확인하며, ⓓ 앞서 보낸 AuthnRequest의 ID와 응답의 InResponseTo가 일치하는지 대조한다. 이 네 가지 검증을 모두 통과해야만 SP는 로컬 세션을 수립하고 자원을 제공한다. 이 검증 단계가 허술하면 뒤에서 설명할 각종 공격에 노출되므로, SAML 보안의 성패는 사실상 'SP의 단언 검증 엄격성'에 달려 있다.

이에 비해 IdP-Initiated SSO는 사용자가 IdP 포털(예: 사내 앱 대시보드)에서 특정 앱을 클릭하면 IdP가 AuthnRequest 없이 곧바로 단언을 생성해 SP의 ACS로 보내는 흐름이다. 사용자 경험은 직관적이지만, SP가 '자신이 보낸 요청에 대한 응답'인지 대조할 InResponseTo가 없어 요청-응답 상관(correlation) 검증이 불가능하고, 그 결과 공격자가 탈취·위조한 단언을 피해자 브라우저로 흘려보내는 로그인 CSRF류 공격에 상대적으로 취약하다. 이 때문에 OWASP와 다수 보안 가이드는 가능하면 SP-Initiated 흐름을 기본으로 채택하고, IdP-Initiated가 불가피하면 단언 일회성 관리와 짧은 유효시간을 강제할 것을 권고한다. 흐름 선택 자체가 보안 설계 결정임을 보여주는 대목이다.

4. SAML과 OIDC·Kerberos 비교

SAML을 올바로 자리매김하려면 유사 기술과의 차이를 '왜 그런 차이가 생겼는가'까지 이해해야 한다. 아래 비교는 단순 나열이 아니라 설계 목적의 차이에서 비롯된 실무적 함의를 담는다.

항목	SAML 2.0	OAuth 2.0 / OIDC	Kerberos
표준화	OASIS(2005)	IETF(OAuth 2012·OIDC 2014)	MIT·IETF(RFC 4120)
데이터 포맷	XML / XML-DSig	JSON / JWT	바이너리 티켓
주 용도	엔터프라이즈 웹 SSO	위임 인가·API·모바일 인증	조직 내부망(도메인) 인증
전송	브라우저 리다이렉트(프런트채널)	리다이렉트+백채널 토큰	TGT/TGS 티켓 교환
적합 환경	B2B·브라우저 중심 SaaS	네이티브 앱·SPA·마이크로서비스	폐쇄망·동일 도메인

SAML과 [[oauth2-oidc]]의 차이는 '태어난 시대와 겨냥한 클라이언트'에서 비롯된다. SAML은 2005년 웹 브라우저가 지배하던 시대에 B2B 웹 SSO를 겨냥해 XML·SOAP 문화 위에서 설계되었다. 반면 OIDC는 2010년대 모바일 앱·SPA(Single Page Application)·REST API가 지배하는 환경을 위해 JSON·JWT 기반의 가볍고 모바일 친화적인 구조로 설계되었다. 그 결과 SAML은 무거운 XML 파싱과 서명 처리가 부담이 되어 네이티브 앱에는 부적합하지만, 성숙한 메타데이터·서명 체계 덕에 엔터프라이즈 웹 SSO에서는 더 보수적이고 검증된 선택으로 남는다. 핵심 구분점은 OAuth가 본래 '인가(무엇을 할 수 있는가)' 프로토콜인 반면 SAML은 '인증(누구인가)'을 포함한 종합 프로토콜이라는 것이며, 그래서 OAuth에 인증 계층을 얹은 것이 OIDC다.

[[kerberos]]와의 차이는 '네트워크 경계'에서 갈린다. Kerberos는 동일 도메인·폐쇄망 내부에서 티켓으로 신속히 인증하는 데 최적화되어 있어 조직 LAN 내 윈도 도메인 로그인에 강하지만, 방화벽을 넘는 도메인 간·인터넷 환경에는 부적합하다. SAML은 반대로 서로 다른 조직·도메인을 브라우저 리다이렉트로 연결하는 인터넷 횡단 페더레이션에 강하다. 실제 기업에서는 사내망 Kerberos 로그인을 SAML IdP와 결합해, 사내에서 한 번 윈도 로그인한 사용자가 외부 SaaS까지 재인증 없이 접근하는 하이브리드 구성이 흔하다.

5. (심화) 주요 보안 위협과 최신 동향

SAML은 성숙한 표준이지만, 구현 결함에서 비롯된 치명적 취약점이 반복적으로 보고되어 왔다. 첫째, XML Signature Wrapping(XSW) 공격은 서명된 원본 단언을 유지한 채 공격자가 조작한 단언을 XML 트리의 다른 위치에 끼워 넣어, 서명 검증기와 단언 처리기가 '서로 다른 노드'를 보도록 만드는 기법이다. 이로 인해 서명은 유효하다고 판정되지만 실제 처리되는 단언은 위조된 것이 되는 심각한 인증 우회가 발생한다. 방어책은 서명 검증 대상과 처리 대상이 반드시 동일 노드가 되도록 강제하고, 스키마 검증과 ID 참조를 엄격히 하는 것이다.

둘째, 서명 검증 누락·관대한 검증이다. 2018년 다수 SAML 라이브러리에서 XML 주석(comment) 처리 차이를 악용해 NameID를 조작하는 취약점(예: user@victim.com<!---->의 주석 삽입으로 다른 사용자로 위장)이 보고되었다. 근본 원인은 서명 범위·정규화(canonicalization) 처리의 불일치였다. 셋째, Replay(재사용) 공격으로, 탈취한 단언을 유효시간 내에 재전송하는 공격은 NotOnOrAfter 엄격 적용과 단언 ID의 일회성(one-time-use) 캐시 관리로 막아야 한다. 넷째, Audience 미검증으로, SP가 Audience 제한을 확인하지 않으면 다른 SP용 단언이 재사용될 수 있다. 이들 위협의 공통 교훈은 'SAML의 보안은 표준 자체가 아니라 SP의 검증 구현 엄격성에 달려 있다'는 점이다.

구체적 사례로, 2020년 전후 다수 상용 SSO 제품과 오픈소스 라이브러리에서 서명 검증·주석 처리 결함이 CVE로 공개되어 대규모 패치가 이루어졌으며, 이는 "검증된 표준도 구현이 틀리면 전면 인증 우회로 이어진다"는 교훈을 남겼다. 따라서 SAML 연동을 신규 구축할 때는 라이브러리 버전·CVE 이력을 반드시 확인하고, 침투 테스트 항목에 XSW·서명 우회 시나리오를 포함하는 것이 바람직하다.

최신 동향으로는, 모바일·API 확산에 따라 신규 연동은 OIDC로 이동하는 흐름이 뚜렷하나 기존 엔터프라이즈 SAML 자산이 방대해 SAML↔OIDC 토큰 교환(brokered federation)을 수행하는 아이덴티티 브로커(Keycloak, Okta, Microsoft Entra ID 등)가 보편화되고 있다. 또한 제로 트러스트([[zero-trust]]) 아키텍처에서 SAML IdP는 지속적 인증·조건부 접근(Conditional Access) 정책의 집행점(PEP/PDP)과 결합되어, 단순 1회 로그인을 넘어 세션 중 위험 신호에 따라 재인증을 요구하는 방향으로 진화하고 있다. 사용자 수명주기 자동화를 위해 SAML(인증)과 SCIM(계정 프로비저닝)을 짝지어 운용하는 것도 현재의 표준 실무다.

6. 고려사항 및 시사점

SAML 도입을 기술사 관점에서 설계·운영할 때 고려할 사항은 다음과 같다.

• 적용 전략(기술 선택 기준): 신규 모바일·API·SPA 중심 서비스에는 OIDC를, 기존 B2B 브라우저 기반 SaaS·대학/정부 연합에는 SAML을 적용하는 '용도 기반 분리'가 합리적이다. 다만 이질적 두 체계가 공존하면 관리 복잡도가 커지므로, 중장기적으로는 아이덴티티 브로커를 두어 두 프로토콜을 중개·수렴시키는 아키텍처를 지향해야 한다.

• 트레이드오프(가용성 대 보안 집중): 인증을 IdP로 집중하면 보안 통제·MFA 일관성은 극대화되지만 IdP가 전사 SPOF가 된다. 따라서 IdP의 액티브-액티브 이중화, 지역 분산, 세션 지속성 설계가 필수이며, IdP 장애 시의 긴급 접근(break-glass) 계정 운영 절차도 사전에 마련해야 한다. 집중의 이득과 집중의 위험을 동시에 설계하는 것이 핵심이다.

• 구현 보안(검증 엄격성 강제): SAML 사고의 대부분은 표준이 아닌 SP 측 단언 검증 결함에서 비롯된다. 서명 검증 대상과 처리 대상의 동일성(XSW 방어), Audience·NotOnOrAfter·InResponseTo 필수 검증, 단언 일회성 관리, 검증된 라이브러리 사용과 정기 패치를 조직 표준으로 못 박아야 한다. 자체 XML 파싱 구현은 지양하고 성숙한 구현체를 재사용한다.

• 운영·거버넌스(수명주기와 로그아웃): SSO는 '한 번 로그인'의 편의와 함께 '한 번 탈취되면 모든 앱이 열린다'는 위험을 동반한다. 따라서 세션 수명·재인증 주기 정책을 조직 차원에서 통일하고, 퇴사·권한변경이 전 SP에 즉시 반영되도록 SAML과 SCIM 프로비저닝을 연계해야 한다. 또한 Single Logout(SLO)은 바인딩·세션 상태 불일치로 실제 구현이 까다로워 일부 SP에 로그아웃이 전파되지 않는 '잔존 세션' 위험이 있으므로, SLO 지원 여부를 연동 심사 체크리스트에 포함하고 미지원 SP는 세션 타임아웃을 짧게 보강한다.

• 전망 및 연계 기술: SAML은 신규 채택이 정체되었으나 기존 자산의 규모 때문에 향후 10년 이상 엔터프라이즈 현장에 잔존할 것이다. 따라서 'SAML을 걷어내기'보다 'SAML을 제로 트러스트·조건부 접근·SCIM 프로비저닝과 통합해 운영 품질을 높이기'가 현실적 전략이다. 중앙 로그를 [[siem]]으로 수집해 인증 이상징후를 탐지하고, 세션 탈취 대비로 재인증 주기·토큰 수명을 단축하는 운영 보강이 병행되어야 한다.

참고자료

• OASIS, "Security Assertion Markup Language (SAML) V2.0 Technical Overview": https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html
• OASIS SAML 2.0 Specifications (Core/Bindings/Profiles): https://wiki.oasis-open.org/security/FrontPage
• Duo Labs, "Duo Finds SAML Vulnerabilities Affecting Multiple Implementations": https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations
• OWASP, "SAML Security Cheat Sheet": https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

---

한 줄 요약: SAML 2.0은 IdP가 서명한 XML 단언을 브라우저가 SP로 전달해 도메인 간 웹 SSO·페더레이션을 실현하는 성숙한 엔터프라이즈 인증 표준으로, 보안의 성패는 SP의 단언 검증 엄격성에 달려 있으며 OIDC·제로 트러스트·SCIM과의 통합 운영이 향후 핵심 과제다.