1. SAML 정의
SAML(Security Assertion Markup Language)은 네트워크를 통해 여러 컴퓨터에서 보안 자격 증명을 공유할 수 있도록 하는 개발형 표준 테이터 포맷으로 2005년 3월 SAML2.0은 OASIS 표준이다.
인증 정보 제공자(identity provider)와 서비스 제공자(service provider) 간의 인증 및 인가 데이터를 XML기반 메시지로 교환하게 된다.
- 인증(Authentication) : 사용자가 자신이 주장하는 사람임을 확인(가입된 사람인지?)
- 권한 부여(Authorization) : 사용자가 특정 시스템이나 콘텐츠에 접속할 수 있는 권한이 있는지 확인(원하는 서비스에 접근권한이 있는지?)
2. SAML기반 인증 흐름
SAML 스펙은 3개의 역할을 정의한다:
- 주체(일반적으로 사용자)
- 인증 정보 제공자(identity provider, IdP) : 사용자 크리덴셜 (사용자명과 패스워드)을 인증하고 SAML Assertion을 발행
- 서비스 제공자(service provider, SP) : 클라이언트가 접근하려는 애플리케이션 또는 서비스
SAML기반 통합 인증 사용예로,
주체는 서비스를 서비스 제공자로부터 요청한다. 이 서비스 제공자(SP)는 식별 어서션(assertion)을 인증 정보 제공자(IdP)로부터 요청하여 가져온다. 이 어서션(assertion)에 기초하여, 서비스 제공자(SP)는 접근을 제어한다. 즉, 연결된 주체에 대해 일부 서비스를 수행할지의 여부를 결정할 수 있다.
아래 이미지는 SAML WebProfile기반의 인증 흐름을 도식화한 것이다.
- Access Resource (애플리케이션 접속)
사용자가 웹브라우저에서 최초로 Service Provider 로 접속한다. 인증 세션이 존재하지 않는다. - Redirect with SAML Authentication Request (인증 요청)
Service Provider 는 인증요청(Authentication Request)를 생성<<일종의 JWT?>>하여 클라이언트 (~ 에이전트 , 브라우저) 로 전송한다.
SP는 iDP(Identity Provider)와 직접 통신하지는 않고, 사용자의 웹브라우저가 iDP로 인증 요청을 redirect한다.
* IdP URL은 사전 정의된 IdP의 SAML 메타데이타로 공유된다. - GET with SAML Authentication Request (인증 요청 획득)
클라이언트는 인증 요청을 그대로 IdP로 전송한다. IdP에 사용자 인증 세션이 존재하지 않는다.
- Challenge for Credential (로그인 요청)
IdP는 사용자 웹브라우저에게 로그인을 요청한다.
* SSO Hub 인증방식은사용자명과 패스워드이며,고객사 SSO 연계시 고객사 SSO의 인증 방식을 사용한다. - Credential (로그인 성공)
사용자는 요구되는 인증방식으로 인증을 시도한다.
*SSO Hub 인증을 사용하는 경우, IdP는 인증 세션을 생성하나,고객사 SSO와 연계하는 경우는 별도의 인증 세션을 생성하지 않는다. - Signed response in hidden HTML form
IdP는 SP를 위해 Subject에 대한 Assertion내용을 포함하는 SAML response를 생성하여 사용자의 웹브라우저로 전송한다. - POST signed response
클라이언트는 Service Provider의 ACS URL에 Assertion을 전송한다.
POST방식과 Redirect방식이 있으나, SSO Hub는 POST방식을 권고한다. - Supply Resoures (자원 접속)
SP는 SAML response로부터 assertion을 추출하여, 인증 세션을 생성하거나, 주체에 대한 애플리케이션 접근을 제한할 수 있다.
서비스 제공자/애플리케이션은 반드시 IdP로부터 인증 확인 메시지를 전달받기 위하여 Assertion Consumer Service (ACS)를 구현해야 하며, Endpoint URL을 IdP에게 제공해야 한다.
SP와 IdP는 인증 흐름중 상호 식별하고, SAML 메시지 교환을 위한 Endpoint URL, 전자서명이나 암호화를 위한 X.509키 정보를 메타데이터로 교환한다.
3. SAML Metadata 이해
SSO 연동을 위해서는 인증서버인 IDP 와 인증을 요청하는 애플리케이션의 SP 메타데이터 정보가 필요하다.
메타데이터는 SAML2.0 Metadata 명세서에 따라 XML로 정의하며, 기본 구조는 아래와 같다.
| XML Element명 | 설명 | 비고 |
| EntitiesDescriptor | 복수의 EntityDescriptor를 정의할 경우, 사용되는 Root Element이다. | |
| (EntitiesDescriptor>?) EntityDescriptor |
하나의 SP혹은 IDP 메타정보 선언을 정의하기 위한 Element이다. | |
| EntityDescriptor> IDPSSODescriptor |
EntityDescriptor의 자식 Element로 IDP 메타 정보를 선언하기 위한 Element이다. | |
| EntityDescriptor> SPSSODescriptor |
EntityDescriptor의 자식 Element로 SP 메타 정보를 선언하기 위한 Element이다. | |
| (IDPSSODescriptor|SPSSODescriptor)> KeyDescriptor | 전자서명, 암호화를 위한 RSA공개키 정보를 선언하기 위한 Element이다. | |
| (IDPSSODescriptor|SPSSODescriptor)> NameIDFormat | 식별 값 포맷을 정의하기 위한 Element이다. | |
| IDPSSODescriptor> SingleSignOnService |
IDP로 인증 요청 메시지 전송을 위한 Endpoint를 정의한다. | |
| SPSSODescriptor> AssertionConsumerService |
IDP로부터 인증 확인 메시지 수신을 위한 Endpoint를 정의한다. | |
| (IDPSSODescriptor|SPSSODescriptor)> SingleLogoutService |
IDP/SP로부터 인증 요청 전송 / 수신을 위한 Endpoint를 정의한다. | |
| SPSSODescriptor> AttributeConsumingService |
IDP로부터 수신할 인증 확인 메시지에 필요한 인증 정보의 속성 요청 정보를 정의한다. |
참고로 IDP 와 SP 메타데이터 XML은 아래와 같다.
IDP 메타데이터 예제
|
<?xml version="1.0" encoding="UTF-8"?>
<EntityDescriptor entityID="saasdev.xxxx"
xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<IDPSSODescriptor WantAuthnRequestsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
MIICKTCCAZKgAwIBAgIET6mOrDANBgkqhkiG9w0BAQUFADBZMQswCQYDVQQGEwJLUjEOMAwGA1UE
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
<SingleLogoutService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="http://saasdev.xx/saasplatform/SingleLogout"/>
<SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="http://saasdev.xx/saasplatform/SingleSignOn"/>
</IDPSSODescriptor>
</EntityDescriptor>
|
SP 메타데이터 예제
|
<?xml version="1.0" encoding="UTF-8"?>
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" ① entityID=”serviceprovider1.com">
<SPSSODescriptor AuthnRequestsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
MIICJzCCAZCgAwIBAgIET6IXlDANBgkqhkiG9w0BAQUFADBYMQswCQYDVQQGEwJLUjEOMAwGA1U
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
②<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://service:8080/ webapp/ssoLogin.do"/>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://service:8080/webapp/ssoLogout.do"/>
<AttributeConsumingService index="0">
<RequestedAttribute FriendlyName="ssoId"
Name="urn:lgcns:dir:attribute-def:ssoId"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/>
</AttributeConsumingService>
</SPSSODescriptor>
</EntityDescriptor>
|
- 통합 인증 메시지 교환에서 서로 식별하기 위한 식별자로 SSO Hub에서 정한 값을 사용한다.
- 인증 기관/서버인 IdP 로부터 인증확인메시지를 수신하기 위한 서비스 정보를 설정한다.
Binding방식으로 HTTP-POST와 HTTP-Redirect를 지원한다.
| 프로파일 | 프로파일명 | HTTP-METHOD | Binding |
| 인증 결과 수신 | AssertionConsumerService | POST | urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST |
| 인증 결과 수신 | AssertionConsumerService | GET | urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect |
4. 보안
SAML은 사용자를 인증을 위한 IdP 서버와 SP간에 안전하게 인증 정보를 교환하기 위하여
암호화 및 전자서명을 위한 XML 암호화/전자서명 표준을 따른다.
5. 다른 인증/인가 기술과 비교
- OAuth
2006년부터 구글과 트위터에서 공동으로 개발한 표준으로 모바일 플랫폼을 위해 개발되었으며, JSON을 기반으로 한다.
SAML 표준은 공급자가 인증 및 권한 부여 서비스를 제공할 수 있는 방법을 정의하지만, OAuth는 권한 부여만 처리한다. - OAuth2
오픈ID 커넥트(OpenID Connect)는 2014년에 개발된 인증 서비스를 제공하며 OAuth 위에 인증을 추가하였다.
최근댓글