Security Assertion Markup Language(SAML)

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