CAS와 SAML에 대하여

최근 Federated Identity에 대한 관심이 많습니다.
우리말로는 "연합 사용자 계정관리" 쯤으로 해석될 수 있는 Federated Identity는 최근 다양한 인터넷 상에 존재하는 리소스들을 연합하여 사용할 경우 최적화된 보안모델을 제공하는 솔루션을 총칭합니다.

흔히 CAS(Central Authentication Service)는 많이 알고 계실 것이라고 생각됩니다. 많은 인터넷 사이트들이 SSO(Single Sign-On)을 구축할 때 CAS를 많이 이용하고 있습니다.

하지만 CAS는 최적화된 SSO라고 할 수 없습니다. 왜냐하면 CAS는 크로스 도메인(Cross Domain)을 지원하지 않기 때문입니다. 이는 CAS에서 생성한 토큰(Token)이 일반적이로 로그인하려는 사용자의 브라우저에 쿠키(Cookie)로 저장되기 때문입니다.

아시다시피 A라는 도메인에서 작성된 Cookie는 다른 도메인에서 접근할 수 없습니다. 이에 대한 보완책으로 URL에 토큰을 달고 다니거나, HTML에 Hidden Field로 서버에서 생성하여 전달해주는 경우가 있지만 결국 사용자에게 쉽게 노출되어 보안상의 위협 요인이 됩니다.

특히 우리가 가장 많이 사용하는 JA-SIG(http://www.ja-sig.org/products/cas/index.html) 경우 웹기반의 SSO를 중심으로 설계되어 있기 때문에 위에서 말한 크로스 도메인에 대한 문제가 존재합니다.

아래 그림은 JA-SIG의 프록시 메커니즘(Proxy mechanism)입니다.

<출처: http://www.ja-sig.org/products/cas/overview/cas2_architecture/index.html>

상기 그림은 웹 브라우져를 중심으로 웹 리소스에 접근하기 위하여 CAS에 티켓을 발급받는 과정을 나타냅니다.


여기서 중요한 문제는 크로스 도메인입니다.

크로스 도메인의 중요성은 점점 커지고 있습니다. 왜냐하면 많은 자원들이 인터넷상에 존재하며 각기 다른 리소스들을 이용하여 더욱 가치높은 정보를 만들어 낼 수 있기 때문입니다.

언뜻 이해하기 어려운 설명이지만 다음과 같은 예를 통하여 쉽게 이해할 수 있습니다.

인터넷에서 자사의 홈페이지(http://java2game.com)를 운영하고 있는 중소 규모의 A사는 최근 직원이 늘어남에 따라 사내 메일 시스템을 구축할 필요성이 대두되었습니다.

메일시스템을 구축하려고 하였으나 메일 시스템의 너무 고비용이라 중소규모의 A사 입장에서는 큰 비용이 소요되는 메일시스템을 구축할 비용이 없었습니다. 하지만 커뮤니케이션을 원활하게 하려면 메일시스템 도입이 절실하였습니다. 또한 검토한 메일 시스템은 대부분 웹상에서 직접 메일을 작성할 수 있도록 웹 페이지를 제공하지 않았습니다.

이러한 고민을 해결하기 위하여 전문가 J씨에게 찾아가 자문을 하였습니다.

J씨는 Google Apps를 추천하였습니다. Google Apps에서는 Gmail 계정을 최대 2000명까지 무료로 제공하고 있으며 프리미엄 기능을 통하여 원활한 확장까지 지원하고 있었습니다. 또한 Gmail의 경우 웹을 통한 메일 작성 및 확인뿐만 아니라 메일 클라이언트를 통하여 쉽게 메일 확인할 수 있도록 지원하고 있었습니다. Google이 호스팅을 해주고 있기 때문에 안전하게 메일 서비스를 이용할 수 있었으며, 따로 메일 시스템을 관리하는 직원을 두지 않아도 되었습니다.


A는 바로 Google Apps를 도입하였는데 한가지 문제가 발생하였습니다. 자사의 홈페이지에 로그인 한 후 Google Apps의 Gmail에 접근할 때 다시 로그인해야 한다는 문제점이었습니다.
이로 인하여 많은 직원들이 불만을 토로하였습니다. 자사의 홈페이지를 사용하다가 Gmail을 사용할 때 2번 로그인하지 않고 쉽게 사용할 수 있는 방법이 필요하였던 것입니다.

단순하게 로그인의 문제가 아니라 결국 효과적으로 웹 상의 회사자원을 연동하여 사용할 수 있는 근본적인 방안이 필요하였던 것입니다.

A사와 같이 웹 상에는 이미 업무를 위한 많은 서비스들이 존재하고 있습니다. 단순하게 E-Mail 서비스뿐만 아니라 스케쥴 관리, 재고관리, CRM, ERP 등등의 서비스들이 이미 웹 상에 구축되어 많은 기업들이 적극적으로 활용하고 있습니다.

하지만 웹 상에 흩어져있는 많은 리소스(정보 등)를 사용자 중심으로 하나로 묶을 수 있는 방안이 없다면 업무효율은 떨어지게 될 것입니다. 물론 하나의 회사에서 이렇게 다양한 서비스를 제공해준다면 큰 문제가 없겠지만 현실적으로 이는 불가능한 일입니다.

이러한 문제를 해결하기 위한 첫번째 단계가 "연합 사용자 계정 관리(Federated Identity)"입니다. 기존의 SSO가 단일한 도메인(회사)을 중심으로 사용자의 계정을 관리하였다면 이제 새로운 SSO는 여러 도메인을 아울러서 하나의 계정으로 관리할 수 있어야 합니다.

이러한 필요에 따라 여러 다른 리소스에 단일한 사용자의 정보를 체계적으로 기술할 수 있는 스펙이 필요하게 되었습니다. 이것이 바로 SAML(Security Assertion Markup Language)입니다.

SAML은 보안 주장(Security Assertion)을 작성할 수 있는 XML기반의 스펙이며, 인증을 필요로 하는 주체간에 SAML의 교환을 통하여 사용자의 정보를 교환하고 이를 통하여 인증(Authentication)과 권한부여(Authorization)를 할 수 있습니다.

특히 SAML은 CAS의 문제점이었던 크로스 도메인 문제를 해결할 수 있으며, 단순한 웹 브라우져 기반의 SSO가 아닌 웹 서비스 등의 다양한 분야에서 활용할 수 있습니다.

이에따라 Google이나 SalesForce.com의 경우 자사의 보안 모델을 SAML을 중심으로 구성하였으며, 이를 바탕으로 자사의 서비스를 무한하게 확장하려고 하고 있습니다.

따라서 SAML은 단순한 보안 스펙이라기 보다는 웹등에 널리 퍼져있는 다양한 리소스를 사용자를 중심으로 단일하게 묶을 수 있는 기반이라고 할 수 있습니다.

또한 SAML을 지원함으로써 더욱 다양한 사업적인 기회를 창출할 수 있는 초석을 마련할 수 있다는 것을 기억하시기 바랍니다.

앞으로 SAML에 대한 여러가지 이야기를 다룰 예정입니다. 관심있는 분들의 많은 피드백 부탁드립니다.

감사합니다.