[Back-end] SAML

Geun·2022년 4월 7일

Back-end

목록 보기

48/74

SAML 이해

SAML(Security Asserting Markup Language)는 보안 인증에 관한 정보를 기술하는 마크업 언어이다.
SAML은 네트워크룰 통해 여러 컴퓨터에서 보안 자격 증명을 공유할 수 있도록 하는 공개 표준이다.
인증/인가 정보를 담은 XML 정도로 간단하게 말할 수 있다.

인증(Authentication) : 사용자가 자신이 주장하는 사람임을 확인
허가(Authorization) : 사용자가 특정 시스템이나 콘텐츠에 접속할 수 있는 권한이 있는지 확인

SAML은 어디에 쓰이는가

SSO(Single Sign-On)을 구현하기 위해 쓰인다. SSO는 한 번의 로그인으로 여러 개의 다른 도메인을 이요하려고 할 때 필요한 기술이다.
애초에 SAML은 웹 브라우저에서의 SSO 문제를 해결하기 위해 OASIS의 연구결과로 탄생하게 되었다.
예를들어, 온프레미스에 이미 구축해 놓은 인증 시스템을 이용해 AWS 리소스에 접근하려고할 때 AWS에 별도의 인증 시스템을 구축하지 않고 온프레미스의 인증을 그대로 쓰려고할 때에 사용한다.

SAML을 통한 인증 프로세스

각 단계별 과정을 설명하면 아래와 같다.

1단계 : 유저는 서비스 제공자(Service Provider)에게 접근한다. (서비스 이용을 위하여)
2단계 : 서비스 제공자는 SAMLRequest를 생성한다. 생성된 SAMLRequest은 XML format의 텍스트로 구성된다.
3단계 : 유저의 브라우저를 이용하여 인증 제공자(Identity Provider)로 Redirect 한다.
4단계 : 인증 제공자(Identity Provider)는 SAMLRequest를 파싱하고 유저인증을 진행한다.
5단계 : 인증제공자(Identity Provider)는 SAML Response를 생성한다.
6단계 : 인증제공자(Identity Provider)는 유저 브라우저를 이용하여 SAMLResponse data를 ACS로 전달한다.
7단계 : ACS는 Service Provider가 운영하게 되는데 SAMLResponse를 확인하고 실제 서비스 사이트로 유저를 Forwarding한다.
8단계 : 유저는 로그인에 성공하고 서비스를 제공받는다.

AWS와 연동은 아래와 같이 구현된다.

1단계 : 조직 내 사용자가 클라이언트 앱을 사용해 조직의 IdP로부터 인증을 요청한다.
2단계 : IdP가 조직의 자격 증명 스토어를 이용하여 사용자를 인증한다.
3단계 : IdP가 사용자에 대한 정보로 SAML 어설션을 만들어 클라이언트 앱으로 보낸다.
4단계 : 클라이언트 앱이 AWS STS AssumeRoleWithSAML API를 호출하면서 SAML 공급자의 ARN, 수임할 역할의 ARN, IdP로부터 받은 SAML 어설션을 전달한다.
5단계 : 클라이언트 앱에 대한 API 응답에는 임시 보안 자격 증명이 포함되어 있다.
6단계 : 클라이언트 앱은 임시 보안 자격 증명을 사용해 Amazon S3 API 작업을 호출한다.

SAML 검증

SAML 검증은 ID 제공자가 사용자 권한 부여 상태를 포함하는 SP로 전송하는 XML 문서이다.
SAML 검증의 세 가지 유형은 인증 ,속성 및 권한부여 결정이다.

인증 검증을 통해 사용자 식별을 확인하고 사용자가 로그인한 시간 및 사용되는 인증 방법(예: 비밀번호, MFA, Kerbeos 등)을 제공한다.
지정된 검증은 SAML 토큰을 SP에 전달합니다. SAML에서 사용자를 식별하는 데 사용되는 속성은 IdP 및 SP 디렉토리에서 동일한 것으로 간주된다. SAML 속성은 사용자에 대한 정보를 제공하는 특정 데이터 부분이다.
권한 부여 결정 검증은 사용자에게 서비스를 사용할 권한이 있는지 또는 ID 제공자가 비밀번호 실패로 인해 요청을 거부했는지 또는 서비스에 대한 권한 부족으로 인해 거부했는지 여부를 나타낸다.

SAML 및 OAuth 사용사례

SAML은 주로 웹 브라우저 SSO(Single Sign-On)을 사용함으로 설정하는데 사용된다.
SSO에 대한 사용자 경험 목표는 사용자가 자격증명을 다시 제출하지 안혹도 한 번 인증하고 별도로 보안 시스템에 접근할 수 있도록 하는 것이다. 보안 목표는 인증 요구사항이 각 보안 둘레에서 충족되도록 하는 것이다.

클라우드 및 온프레미스에서 ID 관리
개방형 표준 통합으로 오버헤드와 유지보수를 줄여 클라우드 및 온프레미스에서 사용자 프로비저닝 및 관리를 간소화한다.
ID 작업 간소화
여러 환경에서 사용자, 역할 및 그룹을 반복적으로 변경할 필요성을 줄여준다.
온프레스 및 클라우드 서비스 전체에서 ID 자격을 동기화하는 ID 브리지를 제공한다.
제로 트러스트(Zero-trust) 전략
적응형 인증을 사용하면 장치, 위치 또는 활동을 기준으로 사용자가 액세스가 위험하다고 판단되는 경우 로그인 요구사항을 늘려 위험을 줄일 수 있다.
소비자 디지털 액세스 권한 관리
유연한 고객 접근 지원을 통해 REST API와 표준 기반 통합을 사용해 타사 서비스와 커스터마이징 애플리케이션을 통합할 수 있다.

SAML과 OAuth 차이

OAuth는 2006년부터 구글과 트위터에서 공동으로 개발한 SAML보다 다소 새로운 표준이다.
OAuth는 모바일 플랫폼에서 SAML의 결함을 보완하기 위해 개발되었으며, XML이 아닌 JSON을 기반으로 한다.

SAML 표준은 공급자가 인증 및 권한 부여 서비스를 제공할 수 있는 방법을 정의한다.
OAuth는 권한 부여만 처리한다.
오픈 ID 커넥트(OpenID Connect)는 2014년에 개발된 더 새로운 표준으로 인증 서비스를 제공하며 OAuth 위에 놓이게 된다.

다른 차이점으로 사용사례가 있다.
SAML은 이론적으로 개방형 인터넷에 사용하도록 설계되었지만, 실제로는 SSO를 위해 엔터프라이즈 네트워크 내에서 배포된다.
반면 OAuth는 구글과 트위터에서 인터넷 규모로 설계되었다.