'Architecture for Software/Security'에 해당하는 글 3건

최근 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에 대한 여러가지 이야기를 다룰 예정입니다. 관심있는 분들의 많은 피드백 부탁드립니다.

감사합니다.
신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글이 없습니다.
secret
SAML에 대한 정의를 명확하게 하고자 내용을 정리합니다. Security Assertion Markup Language(SAML)에 관한 정의는 Wikipedia(http://en.wikipedia.org/wiki/SAML)의 정의가 가장 좋은듯하여 Wikipedia의 내용을 중심으로 정리합니다. 다소 매끄럽지 못하더라도 이해 부탁드립니다.

추후 완벽 정리본을 하나 맹글 생각입니다. ^^


SAML이란

Security Assertion Markup Language(SAML)은 OASIS의 Security Service Technical Committe에서 정의한 보안 도메인간에 인증(authentication)과 권한부여(authorization)에 관련된 자료를 교환할 수 있는 XML 기반의 표준이다. 보안 도메인은 Identity Provider(검증의 생산자)와 Service Provider(검증의 소비자)로 구성되있다.

SAML은 가장 중요한 문제 중 하나인 웹 브라우져 Sigle-Sign-On(SSO)문제를 해결하기 위하여 노력하였다.
SSO 솔루션들은 인트라넷 레벨(예를 들어 Cookie를 사용한)에서 풍부한 해결책들을 제시하였지만 인트라넷을 넘어서는 상호운용성을 지원하지 않은 기술로 문제를 야기하였다.

SAML은  엔터프라이즈 identity management 와 같이 많은 웹기반의 Signle Sign-On(SSO)의 문제들을 해결할 수 있는 결정적인 표준이 될 것이다.

기존의 SSL(Secure Sockets Layer)기반으로 데이터를 전송할 때는 데이터 전체에 대해 암호화를 수행하기 때문에 데이터 자체에 대한 기밀성을 보장할 순 있었으나 데이터의 일부분만 암호화할 경우엔 부적절하였다.
PKI 기반의 인증 보안서비스는 구조 및 코드가 복잡하여 구현할 때 많은 비용과 노력이 요구되는 문제점을 안고 있었다.
이에 반해 XML Encryption 은 이진데이터를 암호화하는 연산과 XML 데이터를 암호화하는 연산으로 나뉘어 XML 데이터를 암호화하는 연산은 데이터 중 일부분 또는 전체를 암호화하여, 중간에 경유하게 되는 제 3 자에게 특정정보를 노출시키지 않으면서 최종 수신자에게 전달할 수 있다. 또한 XML 기반 기술은 데이터의 일부분 또는 전체를 암호화하여 최종 수신자에게 전달할 수 있도록 하면서 복잡한 PKI 방식에 비해 단순한 구조로 이루어
져 시스템 간 손쉽게 데이터를 교환할 수 있다.

SAML 의 역사

SAML 이전의 경우 S2ML(Security Services Markup Language) 과 AuthXML (Authorization XML) 에서 파생된 기술로, SAML 이 출현하기 전에는 기업은 독자적인 인터페이스, 특정한 Single Sign-On 제품 또는 디렉터리 기반 제품 중 하나를 사용해 Single Sign-On 을 해결해야 했다.

SAML 기초

SAML은 다음과 같은 기능을 제공하여 보안 정보의 수신, 전송 및 공유와 관련된 모든 기능을 표준화합니다.

  • 사용자 보안 정보에 대한 XML 포맷을 제공하고 이러한 정보를 요청 및 전송하기 위한 포맷을 제공합니다.
  • SOAP 같은 프로토콜에서 이러한 메시지를 사용하는 방법을 정의합니다.
  • 웹 SSO와 같이 일반적인 특정 이용 사례에 대해 자세한 메시지 교환 방법을 지정합니다.
  • 사용자의 신원을 노출시키지 않고 사용자 속성을 결정하는 기능을 비롯하여 여러 가지 개인 정보 보호 메커니즘을 지원합니다.
  • Unix, Microsoft Windows, X.509, LDAP, DCE, XCML 등 널리 사용되는 기술에서 제공하는 포맷으로 ID 정보를 처리하는 방법을 자세히 알려줍니다.
  • 메타데이터 스키마를 수식화하여 참여하는 시스템에서 지원하는 SAML 옵션과 통신할 수 있도록 합니다.

더욱이 SAML은 높은 유연성 유지를 위해 특별히 설계되어 아직까지 표준으로 해결되지 않는 요구 사항을 처리할 수 있을 정도로 확장이 가능합니다.


SAML 구조


<그림 1>

사용자 삽입 이미지


SAML은 <그림 1>과 같이 플랫폼의 거래 파트너들이 인증정보, 권한부여정보, 그리고 프로파일 정보를 안전하게 교환할 수 있도록 설계된 것이다. 특히 기업 내부 또는 기업 간의SSO를 제공하고 기업 보안 Infrastructure에 종속되지 않는 장점이 있다.

플랫폼 독립적인 SAML 은 Assertion, Profile, Binding, Protocol 로 구성되어 있다<그림 1>.

•  Assertion
Assertion 은 아이덴티티 기관에서 최종 사용자(사람이나 기계)에 대해 만든 구문(Statement)을 말한다. Assertion 은 ‘특정 사용자가 해당 애플리케이션 웹사이트에 대한 접근을 허가 받았는가’와 같은 요청에 응답한다. Assertion 에는 권한 부여(authorization)와 인증(Authentication), 속성(Attribute)등 세 가지 유형이 있다.

• Protocol
SAML Protocol 은 요청과 응답의 포맷을 결정한다.

• Binding
Binding 은 SAML 요청과 응답을 전송하는 방식이다. SAML 에 대해 가장 널리 사용되는 전송 프로토콜은 HTTP 를 통한 SOAP 이지만, OASIS 에서는 SAML 용으로 순수한 HTTP 전송수단에 대한 작업을 진행 중에 있다.

• Profile
SAML assertion 이 메시지 안에서 발견될 수 있는 장소와 같은 것들을 설명하고 있다.


SAML 분석

SAML Assertions

SAML Assertion는 보안 정보 패킷을 포함하고 있다.

<saml:Assertion ...> ... </saml:Assertion>

SAML Assertions는 항상 Indetity Provider로부터 Service Provider로 전송되며 Service Provider가 접근 관리에 대한 결정을 할 수 있는 Statement를 포함하고 있다. Statement는 다음과 같다.

  1. Authentication statements
  2. Attribute statements
  3. Authorization decision statements

Authentication Statement에는 Service Provider에게 사용자가 Identity Provider에게 해당 시간에 유효한 인증 방법을 통하여 인증되었는지에 대하여 알려준다.


SAML Protocols


<그림 2>

사용자 삽입 이미지

SAML Protocol은 어떻게 SAML 엘리먼트들을 SAML Request와 Response 엘리먼트안에서 포장할 것인가에 대한 기술입니다.

SAML Protocol의 Request를 Query라고 부릅니다. Service Provider는 Identity Provider에게 직접 Query합니다. Query 메시지들은 일반적으로 SOAP을 통하여 이루어 집니다.

Query의 유형은 다음과 같습니다.

  1. Authentication query
  2. Attribute query
  3. Authorization decision query



SAML 역할, 어설션(Assertions) 및 문(Statement)

통합 환경은 적어도 다음 세 가지 역할과 관련이 있습니다.

  • 공급 업체(Relying Party) - ID 정보를 사용하는 업체로, 통상적으로 어떤 요청을 허용할 것인지 결정하는 서비스 공급자를 말함.
  • 어설션 업체(Asserting Party) - 보안 정보를 제공하는 업체로, SAML에서는 이들을 " ID 공급자"라고 함.
  • 대상(Subject) - ID 정보와 관련된 사용자

모든 환경에는 여러 개의 대상 및 서비스 공급자가 있습니다. ID 공급자도 여럿이 있을 수 있습니다.

기본적으로 서비스 공급자 또는 공급 업체가 알아야 할 세가지는 다음과 같습니다.

  1. ID 정보
  2. 요청을 하는 업체가 대상이라는 사실
  3. ID 공급자는 이러한 정보를 제공하기로 되어 있다는 사실

SAML에서 어설션(Assertion) 은 이러한 정보를 전달합니다. 어설션에는 머리글 정보, 대상 이름 및 하나 이상의 이 포함되어 있습니다. 머리글에는 ID 공급자 이름 및 발행일 및 만료일 같은 기타 정보가 포함되어 있습니다.

가장 중요한 두 가지 문 유형은 다음과 같습니다.

  • 인증 문(Authentication Statements) - 대상이 특정 시간 및 장소에서 특정 메서드를 사용하여 인증되었음을 보고합니다. SAML은 20가지가 넘는 다양한 인증 메서드를 자세하게 정의합니다. 인증 문은 SSO를 지원하는데, 여기서는 ID 공급자가 서비스 공급자를 대신하여 로그온을 수행합니다.
  • 속성 문(Attribute Statements) - 대상과 관련된 속성을 포함합니다. Groups 및 Roles은 전형적인 속성입니다. 그러나 속성 문에는 재무 데이터 또는 다른 속성도 전달할 수 있습니다.

어설션은 두 가지 유형의 문을 모두 전달할 수 있고 추가 문 유형을 정의할 수도 있습니다. 사실 XACML에서 정책을 전달하기 위한 문 및 권한 부여 결정의 결과를 알려주기 위한 또 다른 문도 정의된 적이 있습니다.

SAML의 강점 중 하나는 유연성입니다. ID 공급자는 어설션을 디지털로 서명할 수 있지만 정보의 무결성을 보장하기 위해 SSL 같은 다른 메서드를 사용할 수 있는 옵션이 있습니다. 어설션(Assertion)에는 대상 확인(Subject Confirmation)이라는 요소가 포함되어 있는데, 서비스 공급자는 이 요소를 사용하여 어설션의 정보가 현재 요청하고 있는 업체를 가리키는지 여부를 결정합니다. SAML을 통해 서비스 공급자는 이러한 목적을 위해 다양한 수단을 사용할 수 있습니다.


바인딩 및 프로파일

SAML 어설션이 ID 공급자에서 서비스 공급자에게로 이동하기는 하지만 서비스 공급자도 다음과 같은 기타 경로를 통해 동일한 작업을 수행할 수 있습니다. 서비스 공급자는 전용 채널을 통해 어설션을 직접 얻을 수 있습니다. 가능성 있는 또 다른 방법은 요청하는 대상이 어설션을 전달하고 이를 서비스 공급자에게 제공하는 것입니다. 세 번째 방법은 또 다른 노드를 통해 어설션을 릴레이하는 것입니다. 웹 서비스 환경에서는 SOAP 머리글이 어설션을 전송할 수 있습니다.

SAML은 서비스 공급자가 어설션을 직접 얻는 데 사용할 수 있는 일련의 요청 및 응답 메시지를 XML에 정의합니다. 이러한 요청 메시지는 예를 들어 "John Smith에 관한 모든 속성"과 같이 서비스 공급자가 원하는 것을 지정합니다. 응답 메시지는 요청에 일치하는 하나 이상의 어설션을 반환합니다. 서로 다른 제품이 상호 운용될 수 있도록 하려면 네트워크 프로토콜이 이러한 요청 및 응답을 전송하는 방법도 지정해야 합니다.

SAML SOAP 바인딩은 SOAP 메시지의 본문에 이를 전송하는 방법을 지정합니다. PAOS 바인딩은 휴대폰과 같이 네트워크로부터 요청을 수신할 수는 없고 보낼 수만 있는 장치를 위해 설계되었습니다. 이것은 HTTP 응답에 전송된 메시지를 사용하여 HTTP 이전 프로그램에서 SOAP를 실행합니다. Browser POST 및 Artifact Profiles은 표준 웹 브라우저 동작을 중심으로 설계되었습니다. POST Profile에서 SAML 응답은 브라우저를 통해 POST 되는 서식으로 눈에 보이지 않는 필드에 전달됩니다. Artifact Profile에서는 Artifact라는 임의의 비트 문자열이 서비스 공급자에게 전달되고, 서비스 공급자는 이를 사용하여 전용 백 채널에서 상응하는 어설션을 요청합니다.

SAML은 통합 ID 환경을 지원하기 위해 여러 가지 다른 메커니즘을 제공합니다. 어떤 프로토콜은 서비스 공급자가 몇몇 가능한 ID 공급자 중에서 특정 클라이언트 요청을 보낼 곳을 결정할 수도 있고, 다른 프로토콜에서는 두 개의 ID 공급자가 동일한 사용자에 대해 소유하고 있는 각각의 계정을 결합할 수도 있습니다. 예를 들어, 한 공급자는 사용자를 John Smith로 알고 있고 다른 공급자는 Jonathan K. Smith로 알고 있을 수 있습니다.(일반적으로 이것은 개인 정보 보호 상의 이유로 사용자 허락이 필요합니다.)

또한 대상의 장기 ID가 노출되지 않도록 개인 정보를 보호하는 임시 식별자를 사용할 수도 있습니다. 위의 예에서 계속해서, 한 ID 공급자는 Subject ABC123이 포함된 어설션이 John Smith를 가리킨다는 것을 알 수 있고, 다른 공급자는 ABC123과 Jonathan K. Smith를 연결할 수 있습니다. 그러나 어느 쪽도 상대가 사용하는 계정 이름을 볼 수 없습니다. 그 다음 날에는 전혀 다른 대상을 사용하여 써드파티가 사용 패턴을 감지하지 못하도록 할 수 있습니다.

SAML은 모든 서비스 공급자 및 ID 공급자에게 사용자가 서명했음을 알리기 위해 간단한 로그아웃 프로토콜을 지정합니다. 이것은 사용자가 시스템을 로그오프했음을 보장하기 위한 메커니즘이라기 보다는 주로 리소스 정리 시 편의를 위한 것입니다. 그 밖에 SAML의 유용한 기능은 다음과 같습니다.

  • 어설션 전체 또는 중요한 부분만 암호화
  • 어설션의 의도된 소비자 지정 .

또한 SAML 표준에는 다양한 기능 조합에 대한 상세한 준수 기준과 보안 및 개인 정보 보호 고려 사항에 관한 문서가 포함되어 있습니다.



SAML Use Case





SAML 을 사용한 인증 시나리오

SAML 생성은 사용자가 최초의 인증을 받을 때 소스 사이트를 통하여 만들어지며 이는 토큰과 같은 형식으로 생성된다. SAML 인증 모델은 크게 두 가지로 나뉘어 조금 다르게 동작된다. Pull 모델과 Push 모델이 그것이다.

SAML 인증 Pull 모델<그림 3>에서 end host 는 소스 사이트에 assertion 을 요청한다. 소스사이트는 인증/승인 과정을 거쳐 artifact 를 생성하고 사용자에게 전송한다. Artifact 는 assertion 의 특별한 형태이다. Artifact 는 소스사이트에 저장되어 있는 assertion 을 참조하는 포인터와 같다.

웹 사용자가 목적지 웹사이트에 자원을 요청하면 소스 웹사이트는 사용자에게 artifact 를 전달함과 동시에 목적지 웹사이트로 경로 재설정을 수행한다. 목적지 웹사이트는 수신한 artifact 를 소스 웹사이트에 전달하고 해당 assertion 을 전달받는다. 마지막으로 목적지 웹사이트에서는 수신한 assertion 을 분석하고 적합한 요청일 경우 SOAP 이나 HTTP 같은 전송 프로토콜을 사용해 웹 사용자에게 요청 자원을 전달한다.

<그림 3> Artifact 기반의 SAML Pull 모델
사용자 삽입 이미지


SAML Push 모델에서는<그림 4> 사용자가 소스 웹 사이트에 ID/Password 기반으로 인증 요청을 하고 소스 웹사이트에서 인증/승인 후 인증 사용자에 해당하는 Assertion 을 생성한다. Pull 모델에서와 같이 사용자는 후에 소스 사이트에 목적지 웹사이트의 자원을 요청하고 소스 사이트는 요청자에게 assertion 을 전달함과 동시에 목적지 웹사이트로 경로 재설정을 수행하게 된다. 목적지 웹사이트는 요청자로부터 assertion 을 전달받은 후에 소스 웹사이트와의 별도의 프로토콜 통신인증 없이 사용자를 인증하게 된다.


<그림 4> Assertion 기반의 SAML Push 모델
사용자 삽입 이미지

-<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
AssertionID="cT_S_T-vKMwidT8_Pzkke8UkC68."
IssueInstant="2004-02-25T16:31:03Z"
Issuer="http://aaremote.entegrity.com"
MajorVersion="1" MinorVersion="1"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<saml:Conditions NotBefore="2004-02-25T16:26:03Z"
NotOnOrAfter="2004-02-25T16:36:03Z" />
-<saml:AuthenticationStatement
AuthenticationInstant="2004-02-25T16:30:58Z"
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:pa
ssword">
+<saml:Subject>
-<saml:SubjectConfirmation>
<saml:ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:cm:bearer
</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:SubjectLocality IPAddress="192.168.4.1" />
</saml:AuthenticationStatement>
-<saml:AttributeStatement>
+<saml:Subject>
+<saml:SubjectConfirmation>
</saml:SubjectConfirmation>
</saml:Subject>
+<saml:Attribute AttributeName="AssuranceLevel"
AttributeNamespace="http://www.oasisopen.
org/RSA2004/attributes">
</saml:Attribute>
+<saml:Attribute AttributeName="E-mail"
AttributeNamespace="http://www.oasisopen.
org/RSA2004/attributes">
</saml:Attribute>
+<saml:Attribute AttributeName="MemberLevel"
AttributeNamespace="http://www.oasisopen.
org/RSA2004/attributes">
</saml:Attribute>
+<saml:Attribute AttributeName="commonName"
AttributeNamespace="http://www.oasisopen.
org/RSA2004/attributes">
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>

위는 SAML 기반의 인증과정을 거쳐 생성된 Assertion 의 형식을 나타낸 것으로 이와 같이 XML 기반의 Assertion 은 사용자 요청을 인증/승인할 수 있는 충분한 정보를 담고 있다.


참고문서
  • Security Assertion Markup Language(SAML): http://en.wikipedia.org/wiki/SAML
  • SAML의 실체: http://www.dev2dev.co.kr/pub/a/2005/11/saml.jsp
  • OASIS의 SAML: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
  • Project Liberty: http://www.projectliberty.org/
  • OASIS의 XACML: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
  • SAML 기반의 사용자와 OSS 간 안전한 정보교환을 위한 관리시스템: http://www.knom.or.kr/knom-review/v7n2/1.pdf
신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글이 없습니다.
secret
최근 통합된 ID 관리 방안이 많은 사람들의 관심을 끌고 있습니다.

필자역시 회사에서 Service Platform을 추진하고 있으며 이에 따라 최적화된 ID 관리를 위한 방안에 많은 관심을 가지고 있습니다. 마침 ETRI에서 오픈소스 ID 관리 프로젝트 동향이란 글을 읽고난 후 ID 관리에 동향에 관한 내용을 정리하고자 합니다.

사용자 삽입 이미지

상기 그림에서와 같이 Open Source 진영의 ID 관리는 여러 방면에서 추진되고 있습니다. 타원형은 개발 프로젝트를 의미하고 사각형은 관리 프로젝트를 의미합니다.

ID 관리 프로젝트가 오픈소스로 진행하는 것은 다음과 같은 문제를 해결하기 위해서입니다.
  • 인터넷 상의 ID 문제는 하나의 업체 또는 표준으로 해결할 수 있는 문제가 아님.
  • 고객들이 ID 관리 시스템들 간의 호환성과 구축의 용이성을 요구함
  • 업계 표준화(de facto)를 이루기 위하서는 광범위한 분야에 적용되어야 함.
  • 다양한 ID 관리 표준들이 존해하기 때문에 표준화만으로는 업게의 동의를 얻기 어려움
  • 표준을 준용하더라도 상호운용성 시험을 거쳐야지만 호환성을 보장할 수 있음.

ID 관리 기술은 크게 인증, 인가, 접근제어, 감사 및 법률적 규제로 나눠서 볼 수 있습니다.

대표적인 오프소스 프로젝트는 다음과 같습니다.
  • OpenSSO
  • Shibboleth
  • JAX-WS
  • OSIS
  • Higgins
  • Bandit
  • Heraldry

각 오픈소스 프로젝트에 대한 설명은 다음과 같습니다.

사용자 삽입 이미지

OpenSSO는 Sun의 ID 관련 제품의 기반 기술을 담당하는 웹 SSO(Single-Sign-On) 프로젝트로서 2006년 8월 17일 릴리스되었다.
OpenSSO 프로젝트는 어떠한 웹 기반의 어플리케이션이라도 서로간의 인증, 세션 로깅 서비스를 통하여 ID 기반의 인증과 SSO 기능을 제공하는 서비스 인프라 역활을 수행한다.

OpenSSO 프로젝트가 제공하는 서비스 목록에는 인증, 정책(인가) 관리, SAML, Federated Identity, Session 관리, Log 관리가 있다.

현재 OpenSSO는 Java System Access Manager의 핵심을 담당하고 있다.

라이센스는 CDDL을 사용한다.


사용자 삽입 이미지

sh를 발음할 수 없었던 에브라임 사람(Ephraimites)을 길르앗 사람(Gileadites)과 구별하기 위해 시험으로 사용되었던 말이라는 뜻의 Shibboleth는 미국의 교육 및 학술분야를 위한 Internet2의 미들웨어 아키텍처 프로젝트로 웹 기반의 리소스를 위한 인증 및 접근 제어 시스템이다.

Shibboleth의 목적은 다음과 같다.
  • OSASIS SAML v1.1 표준을 완벽히 구현하여 제공
  • OpenSAML 기반으로 하여 Federated SSO와 Attribute Exchange 기능 스행을 위한 프레임웍 제공
  • 사용자가 직접 Attribute 공유를 제어할 수 있는 확장된 Privacy 기능 제공
Shibboleth 프로젝트의 핵심 서브 프로젝트로서 Java와 C++언어로 SAML 스펙을 구현하는 OpenSAML 프로젝트가 있다. OpenSAML 1.1의 경우 Apache의 Xerces와 XML-Security를 기반으로 만들어졌다.

라이센스는 Apache 2.0을 사용한다.


사용자 삽입 이미지
JAX-WS는 Sun의 GlassFish의 하위 프로젝트로서 XML 웹 서비스를 위한 Java용 API(JAX-WS) 스펙 구현을 목표로 한다. 특히 웹 서비스간의 상호운용성을 가능하게 하는 기반 기술을 제공하여 Microsoft의 통신 기술과 상호운영을 가능하게 만들어 준다.

JAX-WS 프로젝트의 하부 프로젝트로 Project Tango로 명명된 WSIT가 있다. WSIT의 기능은 다음과 같다.
  • 초기화 통신: WCF(Windows Communications Foundation)기반의 서비스로부터 WSDL을 획득하기 위한 서비스, WS-Metadata Exchange, WS-Transfer
  • 최적화 통신: 최적화된 바이너리 인코딩을 통하여 메시지 크기를 줄이고 보안통신을 위한 초기 설정을 수행하는 서비스, WS-Secure Conversation, WS-Policy
  • 신뢰성: 메시지 손실 또는 순서오류 문제로 인한 전송 실패를 복구하는 서비스, WS-Reliable Messaging
  • 단일 트랜잭션: 한 트랜잭션 경게내에 있는 모든 연산이 성공적으로 수행되었음을 보장하는 서비스, WS-Atomic Transaction, WS-Coordination
  • 보안통신: 메시지 레벨에서 보안기능과 보안 토큰 생성 기능을 제공하는 서비스, WS-Security, WS-Security Policy
WSIT 프로젝트는 2007년 2월에 베타버전을 공개하였으나 WS-MetadataExchange, WS-Security, WS-Atomic Transaction, WS-Security Policy 표준 지원이 부족한 상태입니다.

라이센스는 CDDL을 사용하고 있음.

사용자 삽입 이미지

OSIS는 2006년 6월에 개최든 Indenitity Mashup 컨퍼런스에서 발족된 프로젝트로서 Microsoft, Novell, IBM, SXIP, XRI, Verisign과 같은 여러 업체가 참여하고 있다. 설립초기에는 Microsoft의 CardSpace 제품에 대한 오픈소스 버전을 작성한다는 목표를 가졌으나 지금은 그 범위를 확장하여 오픈소스 관리 프로젝트들을 체계적으로 관리한다는 목표를 설정하였다.

사용자 삽입 이미지
Higgins 는 Novell과 IBM에 의하여 시작되었으며 Eclipse 재단에서 주관하는 프로젝트이다.
Higgins는 재사용이 가능하고 플랫폼과 ID 프로토콜에 무관하며 간편하게 Privacy와 ID 정보를 제어할 수 있는 소프트웨어 프로토콜을 제공하는 것을 목표로 한다.


사용자 삽입 이미지
Bandit 은 Novell이 주관하는 프로젝트로 인증, 인가, 감사와 같은 ID 서비스를 Loosely-coupled 구조의 Component로 제공한다.


사용자 삽입 이미지

Heraldry는 현재 Apache의 인큐베이팅을 마친 후 은퇴한 상태이다. 따라서 아래 문서의 내용과 현재 상태가 강이할 수 있으니 참고하기 바란다. 현재 OpenID에 관련된 내용이 옮겨진 상태이다. 따라서 OpenID를 참고하기 바란다.

이상으로 Open Source 기반의 ID 관리 솔루션들에 대하여 간략하게 살펴보았다. 자세한 내용은 첨부한 PDF문서를 참고하기 바란다.



신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글  2개가 달렸습니다.
  1. 오, 정보 감사요~ 제 블로그로 퍼갈께요~
secret