글 싣는 순서
1. SSO의 개요
2. SAML 2.0 Deepdive (상)
3. SAML 2.0 Deepdive (하)
시작하며
SSO에 대한 기본적인 개념을 바탕으로 SAML 2.0 프로토콜에 대해 살펴보겠습니다. SSO에 대한 관심이 많다보니 은근히 인기를 끄는 글입니다.
SAML 2.0 의 개요
SAML 은 Security Assertion Markup Language 의 약어로 같은 네트워크 내의 인증과 권한에 관한 데이타를 서로 교환하기 위한 표준입니다. SAML을 이용하면 사용자를 인증을 위한 IdP 서버와 SP간에 안전하게 인증 정보를 교환할 수 있습니다. 요즘 많은 기업에서 SAML 2.0 기반의 SSO를 구현하는 이유는 다음과 같은 이점이 있기 때문입니다.
암호 피로 (Password fatigue) 감소
사용자가 여러 개의 비밀번호와 유저 네임의 쌍을 외워야 하는 정신적인 피로도를 의미하는 암호피로의 감소
인증 위임
다수의 Service Provider 와 단 하나의 IdP 간의 CoT를 생성하여 IdP로 인증 위임되므로 사용자는 단 한번의 로그인으로 다수의 Service Provider를 사용할 수 있음안전한 인증 정보의 보호
IdP, SP, 사용자 사이에서 교환되는 인증정보를 암호화개인 생산성 향상
지속적으로 패스워드를 재입력하는 과정이 생략되고, 패스워드 재설정 및 복구에 따른 과정이 필요없음
시스코의 UC 애플리케이션의 경우 SAML 2.0을 지원하는 대부분의 IdP와 연동이 가능하지만, 제조사에서 직접 테스트한 IdP는 다음과 같습니다.
- Microsoft Active Directory Federation Services (ADFS) 2.0
- Open Access Manager (OpenAM) 11.0
- PingFederate 6.10.0.4
- F5 BIP-IP 11.6
SAML 기반의 SSO 주요 요소
SAML 의 동작 방식을 이해하기 위해서 먼저 몇가지 구성 요소를 살펴보겠습니다. .
클라이언트
웹브라우저 또는 단말Service Provider
클라이언트가 접근하려는 애플리케이션 또는 서비스 (웹엑스 또는 재버)Identity Provider(IdP)
사용자 크리덴셜 (사용자명과 패스워드)을 인증하고 SAML Assertion을 발행SAML Assertion
사용자 인증을 위해 IdP로 부터 SP로 전달되는 보안 정보
사용자명, 권한 등의 내용을 적은 XML 문서로 변조를 막기위해 전자서명됨SAML Request (인증 요청)
Service Provider 가 생성하는 인증 요청으로 IdP로 인증 위임Circle of Trust (CoT)
하나의 IdP를 공유하는 Service Provider 들로 구성Metadata
SSO를 활성화하는 Service Provider 및 IdP 가 생성하는 XML 파일
메타데이타의 교환으로 신뢰 관계 설립Assertion Consumer Service (ACS) URL
ACS URL은 IdP가 특정 URL로 최종 SAML 응답을 포스트하도록 요구한다.
SAML SSO 은 Assertions, 프로토콜, 바인딩 그리고 프로파일의 특별한 결합입니다. 여러가지 Assertion은 프로토콜과 바인딩을 사용하는 애플리케이션과 사이트 사이에서 교환됩니다. 이 Assertion은 사이트간의 사용자들을 인증합니다.
SAML 2.0 에서 Trust Agreement
SAML SSO는 IdP와 SP 간이 프로비져닝 과정에서 인증서와 메타데이타(metadata)를 교환하므로서 CoT (신뢰 체인, Circle of Trust)를 설립합니다. 이를 통해 Service Provider는 IdP의 사용자 정보를 신뢰합니다.
SAML 2.0 에서 IdP와 Service Provider 간에 신뢰관계를 맺기 위해서는 각각의 메타데이타를 교환해야 합니다. 각각의 메타데이타를 생성하면 다음과 같은 XML문서로 나타납니다.
Service Provider의 메타데이타는 <md:EntityDesciptor>로 시작하며, IdP의 메타데이타는 <md:IDPSSODescriptor>로 시작합니다. 실제 교환은 관리자에 의해 수동으로 (Copy & Paste)으로 전달되는 가장 확실한 방식을 주로 사용합니다.
SAML 2.0 기반의 인증 과정
IdP와 Service Providor 간에 메타데이타를 교환하여 신뢰 관계 설립한 후 SAML 2.0 은 다음과 같이 동작합니다.
SAML 기반의 인증 과정은 다음과 같습니다.
Access Resource (애플리케이션 접속)
사용자가 웹브라우저에서 최초로 Service Provider 로 접속합니다. 아직 웹브라우저가 세션을 활성화한 상태는 아닙니다.Redirect with SAML Authentication Request (인증 요청)
Service Provider 는 인증요청(Authentication Request)를 생성하여 클라이언트로 전송합니다.
IdP URL은 SAML 메타데이타 교환 과정에서 사전 구성됩니다. SP는 iDP와 직접 통신하지는 않고, 사용자의 웹브라우저가 iDP로 인증 요청을 redirect 하도록 합니다.
인증 요청은 다음과 같이 보입니다.HTTP/1.1 302 Found
Location: https://pingsso.home.org:9031/idp/SSO.saml2?SAMLRequest=nZLNbtswEITveQqCd1m0pKoWYRlwYxQ1kDZK5OaQG02tYwISqXLJtH37kkra%2FBjwodflcPab3V2iGPqRr7076lv44QEdIb%2BGXiOfXmrqreZGoEKuxQDIneTt%2BusVz2aMj9Y4I01PL7abmmJWVCxnku07sYCqFAu2KGWVdaycV1AWRbnPPjJZlDkld2BRGV3TYEPJFtHDVqMT2oUSm%2BcJq5Ks2LGK5x84K%2B8p2QQ0pYWbfh2dG5Gn6aj0A6KZHc0AM2MfeACYp6ob07a9nsUEGSWfjZUwJazpQfQIsWEjENUj%2FKs0z1E%2BKd0F0%2FO5908i5F92uyZprtsdJWtEsJHu0mj0A9gW7KOS8P326oVXejkk4F94F0WRpyEBjmmkjdip6JXAEyldXSyjhE%2FDsq%2BWdJ5V%2FOWiq%2FeWy%2FSV4bP9yL8Fi%2B2mMb2Sv%2F%2FnFuK8B%2BHOq2NFdclhknJnhUYF2lHSNrH%2FjQ9DOCiwNT2ZA1n3vfl5aUG4sD5nPdDVU5K37CFQenrdqz8%3D&RelayState=s249030c0bda8e96a8086c92d0619e6446b270c463
인증 요청을 아래와 같이 디코딩하였습니다.
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"ID="s249030c0bda8e96a8086c92d0619e6446b270c463"
Version="2.0"
IssueInstant="2013-09-19T09:35:06Z"
Destination="https://pingsso.home.org:9031/idp/SSO.saml2"
ForceAuthn="false"
IsPassive="false"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AssertionConsumerServiceURL="https://cucm-eu.home.org:8443/ssosp/saml/SSO/alias/cucm-eu.home.org">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">cucm-eu.home.org</saml:Issuer>
<samlp:NameIDPolicy xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
SPNameQualifier="cucm-eu.home.org"
AllowCreate="true"
/>
</samlp:AuthnRequest>
GET with SAML Authentication Request (인증 요청 획득)
클라이언트는 인증 요청을 그대로 IdP로 전송합니다. 아직 사용자의 브라우저는 IdP와 세션이 활성화되지 않았습니다.
Challenge for Credential (로그인 요청)
IdP는 사용자 웹브라우저에게 로그인을 요청합니다. 인증방식은 사용자명과 패스워드, PKI 등 다양하게 사용할 수 있습니다.Credential (로그인 성공)
클라이언트는 요구되는 인증방식으로 인증을 시도합니다. 이과정에서 Service Provider는 개입하지 않습니다. IdP가 LDAP 서버로 인증을 다시 위힘할 경우에는 LDAP으로 경로가 증가하지만 여기서는 생략합니다.Signed response in hidden HTML form
IdP는 SP를 위해 SAML response를 생성하여 사용자의 웹브라우저로 전송합니다. SAML Response는 SAML assertion이 포함됩니다. iDP는 웹브라우저에 Session cookie (세션 쿠키)를 설정하고, 이정보는 웹브라우저에 캐싱됩니다.POTS signed response
클라이언트는 Service Provider 의 ACS URL에 Assertion을 포스팅합니다.Supply Resoures (자원 접속)
SP는 POST로 부터 SAML assertion을 추출합니다.
마치며
SAML 2.0 Flow에 있는 프로토콜 절차는 IdP-initiated SSO일까요? SP-intiated SSO일까요? 답을 안다면 SAML 에 대한 기본적인 이해는 된 것입니다. 다음 글에서는 세션 쿠키에 대해 좀 더 자세하게 살펴보겠습니다. 나중에 개인적으로 여유가 된다면 SMAL 2.0을 CUCM에서 활성화하는 과정을 데모로 정리해보곘습니다.
참조자료
Cisco.com : SAML SSO Deployment Guide for Cisco UC Applications 11.0
위키피디아 : SAML 2.0
OASIS : SAML 2.0 Technical Overview
라인하트 유씨누스 (CCIEV #18487) _________________________________________________________
ucwana@gmail.com (라인하트의 구글 이메일)
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항)
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스)
http://groups.google.com/group/ucforum (UC를 공부하는 사람들이 모인 구글 구룹스)
세상을 이롭게 하는 기술을 지향합니다. ________________________________________________________
