사례 연구
Average rating:  (18 ratings) |
Sam Thompson
jStart Program Manager for Web services, IBM
2003년 4월 1일
부상하고 있는 WS-Security 표준이 2002년 가을에 개발된 웹 서비스의 보안에 어떻게
사용되었는지를 설명한다. 이 글에서는 웹 서비스의 보안 관련 요구사항들을 검토하고, HTTPS/SSL, 디지틀 인증, 디지틀
서명 등을 결합하여 이러한 요구들을 충족시키는 방법에 대해 논의할 것이다. 웹 서비스를 실행하는 데 사용되는 SOAP 메시지의
WS-Security 요소를 검토하면서 WS-Security 요소의 각 부분을 설명할 것이다. 이 글을 읽은 후에 여러분은 웹
서비스 애플리케이션 제품에서 WS-Security를 사용하는 방법에 대한 이해력이 성장할 것이며 자신의 프로젝트에 이 떠오르는
표준을 사용할 것에 대한 확신을 갖게 될 것이다.
웹 서비스 보안 - 비지니스를 위한 준비
지
난 2년 동안 웹 서비스는 과도하게 선전된 기술에서 많은 조직들이 생산적으로 사용하고 있는 기술로 변모했다. 모든 새로운 기술
프로젝트가 그렇듯, 초기 구현은 작고, 방화벽 안에 존재하며 중요한 작업에는 쓰이지 않는 "샌드박스" 유형의 노력 또는
프로젝트가 되는 경향이 있었다. 인터넷을 통해 웹 서비스를 전달하려는 모험을 시도했던 용감한 영혼은 누구에게나 개방되고 누구나
사용할 수 있는 서비스를 제공해야 한다는 것 또는 자신만의 지적소유권을 갖고, 철저히 기업 스팩의 보안 스키마를 개발해야 한다는
것을 깨닫게 되었다.
인터넷을 통신수단으로서 사용하는 초기 채택자들은 일반적으로 공개된 인터넷 서비스를 위해 일종의 등록 절차를 사용했고 매우
신뢰성있는 관계를 이미 갖고있는 소수의 비지니스 파트너들에게 서비스를 제공했다. 예를 들어 Google의 웹 서비스 기능의 검색
엔진을 사용하기 위해서는 서비스 요청자는 HTML 기반의 형식을 통해 Google에 등록해야한다. 등록 절차의 일부로서
Google은 보안 "토큰"이 있는 이메일을 요청자에게 보낸다. 요청자가 서비스를 호출하면 그들은 SOAP 메시지의 일부로서
Google에 이 토큰을 제공하여 그들이 Google 웹 서비스에 등록 및 권한을 부여받은 사람인지를 확인한다.
이러한 상황에서 서비스 제공자가 SOAP 같은 산업 표준을 사용하고 있더라도, 서비스 요청자가 서비스를 사용하려면 보안
스키마/프로세스와 관련한 추가 정보가 필요했다. 이는 요청자와 제공자를 강결합하는, 원치않는 효과를 만들어냈다.
WS-Security 표준
웹 서비스를 안전하게 할 산업 표준의 방법은 분명 필요했고, IBM, Microsoft, VeriSign은 2002년 4월 이러한 필요에 대한 반응을 보였다. (참고자료)
"WS-Security는 메시지 무결성, 메시지 기밀성, 단일 메시지 인증을 통한 품질 보호를 제공하기 위해서 SOAP 메시징의 보강 사항을 설명하고 있다. 이러한 메커니즘은 다양한 보안 모델과 암호화 기술에 적용될 수 있다.
WS-Security는 또한 보안 토큰과 메시지를 결합 할 범용의 메커니즘을 제공한다. 특정 유형의 보안 토큰도
WS-Security에서 요구되지 않는다. 이는 확장성을 목적으로 설계된다. (예: 다중의 보안 토큰 포맷 지원). 예를 들어
클라이언트는 특별한 비지니스 인증을 갖고 있다는 것을 입증할 무언가(id)를 제공해야한다."
1997년 이후, IBM은 jStart(jump-start의 약자, 참고자료)
라는 프로그램으로 고객과 비지니스 파트너가 이 새로운 기술을 이용할 수 있도록 했다. 이 프로그램의 목적은 초기 채택자들이
새로운 기술을 사용하여 비지니스를 좀더 성공적으로 만들 수 있도록 하는 것이였다. 지난 가을 jStart 프로그램은 인터넷을
통해 B2B 웹 서비스를 제공하고자 하는 기업들이 사용했다. 그들은 높은 수준의 보안 및 상호운용성을 요구했고 IBM은 SOAP
메시지 트래픽을 보안하는 WS-Security 접근방식을 이들 비지니스 파트너와의 통신에 사용하기로 결정했다.
왜 WS-Security 인가?
고객의 애플리케이션에 사용 사례들이 늘어나게되면서 보안과 관련된 비 기능적 요구사항들이 확인되었다:
- 고객과 고객의 비지니스 파트너 간 통신이 인터넷 상에 흐를 때 제 삼자는 이를 볼 수 없어야 한다.
- 메시지가 어디에서 왔는지를 결정할 수 있고 보낸사람이 승인된 것인지를 확인할 수 있다.
- 전송되는 데이터가 조작되는 일이 없도록 해야한다.
요구사항 중 1번은 HTTPS/SSL 전송 보안을 사용하여 해결 될 것이다. 이 애플리케이션은 P2P 애플리케이션이기
때문에 제 삼자의 서비스 제공자나 중재자도 개입되지 않고 SOAP 메시지의 일부 또는 전체를 암호화 하는 생각도 고려되었지만 이
당시 구현되지 않았다. 제 삼자가 개입되지 않는다면 SOAP 메시지의 세그먼트를 암호화하는 추가 암호 단계에서 얻어진 값으로는
추가 개발 비용과 메시지 레벨의 암호 구현에 필요한 복잡성을 가늠하기에 충분하지 않다.
2번과 3번은 디지틀 서명과 디지틀 인증을 사용해서 접근 할 수 있다. 디지틀 인증 접근방식을 사용할 때 웹 서비스
요청자는 공신된 인증 허가를 통해 서명된 디지틀 인증을 갖고있어야 한다. 요청자는 이 인증을 사용하여 id를 선언하고 요청자의
id와 메시지의 무결성을 확인하기 위해 SOAP 메시지의 디지틀 서명을 수행한다.
일단 고객 시스템에서 메시지를 받으면 타임 스탬프가 찍히고 기록된다. 이 부분에서 디지틀 서명이 유효화된다. 타당성검사
프로세스는 메시지가 전송자에게서 왔다는 것을 확인하고 그 메시지 콘텐츠가 전송자의 사이트에서 서명된 이후 수정되지 않았다는 것을
확인한다.
웹 서비스
이
러한 요구사항과 기술적 접근방식에 대해 이해했다면 이제는 무엇이 구현되었는지를 보자. 고객이 웹 서비스로서 구현하기로 선택한
WebSphere Studio Application Developer와 IBM alphaWorks 웹 사이트의 툴(XML
Security Suite, Apache Axis)을 사용하여 구현되었다. 비록 이러한 접근방식이 고객의 핵심 비지니스
애플리케이션을 가동시킬 때 매우 강력하지만 하나의 방식을 구현한다는 점에서 단순하다고 볼 수 있다. 이것은 WebSphere
Application Server에 전개되었고 WebSphere MQ Series를 통해 고객의 핵심 비지니스 애플리케이션과
인터랙팅한다.
Application Developer의 일부인 TCP/IP를 사용하여 웹 서비스 프로세싱을 위해 보내진 SOAP 메시지를
캡쳐했다. 고객의 기밀을 보장하기위해서 SOAP URL을 만들고 애플리케이션 스팩의 SOAP 페이로드를 지우고 몇몇 계산된 값은
변경했다:
1. <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
2. <soapenv:Header>
3. <wsse:Security soapenv:actor="http://www.jStartcustomer.com/actors#verifier"
soapenv:mustUnderstand="1"
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
4. <SignedInfo>
5. <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
6. <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
7. <Reference URI="#sign_content_1043176028580">
8. <Transforms>
9. <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
10. </Transforms>
11. <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
12. <DigestValue>FLuQTa/LqDIZ5F2JSaMRHSRuaiQ=</DigestValue>
13. </Reference>
14. </SignedInfo>
15. <SignatureValue>
16. kGlrrXjKku/WXKxID+JJkEXY+aGNYHc5dy8GwbLFtB5Msll2/MhwdnO9wastJ0gLPzLy3oHL
17. 7A8ggkMkjgAqnLg6PTzM7MdKoIAhe+xRHdOysamGucFJQRMrU+JQ4WATJt0bpdClwJy6mexT
18. Su48mq1q5rM9YZh61P7UEUKt+EQ=
19. </SignatureValue>
20. <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
21. <KeyValue>
22. <RSAKeyValue>
23. <Modulus>
24. 2sW+eBjx5D2QMyr8ocZIZWNYHGf9zYhB4XWILPCTvhNV7dIe3l8ARepOA1ABFK2OMy
25. pzb+Rb+nWQeo//yFz/28PmL63kdLiE72qmmQuzuPa5NXaV9pJ4JKw86QdLhGGpFIRH
26. 18Iugf3xLFwQEZqKYnblTUs7ftnTgW5r4HH492k=
27. </Modulus>
28. <Exponent>AQAB</Exponent>
29. </RSAKeyValue>
30. </KeyValue>
31. <X509Data>
32. <X509IssuerSerial>
33. <X509IssuerName>OU=Java,O=IBM,L=Unknown,ST=Oklahoma,C=US</X509IssuerName>
34. <X509SerialNumber>0</X509SerialNumber></X509IssuerSerial>
35. <X509SubjectName>CN=John Doe</X509SubjectName>
36. <X509Certificate>
37. MIIB0TCCAToCAQAwDQYJKoZIhvcNAQEEBQAwTzELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE9rbGFo
38. b21hMRAwDgYDVQQHEwdVbmsam3duMQwwCgYDVQQKEwNJQk0xDTALBgNVBAsTBEphdmEwHhcNMDIw
39. OTI1MTAxMTQ4WhcNMDMwOTI1MTAxMTQ4WjATMREwDwYDVQQDEwhKb2huIERvZTCBnzANBgkqhkiG
40. 9w0BAQEFAAOBjQAwgYkCgYEA2sW+eBjx5D2QMyr8ocZIZWNYHGf9zYhB4XWILPCTvhNV7dIe3l8A
41. RepOA1ABFK2OMypzb+Rb+nWQeo//yFz/28PmL63kdLiE72qmmQuzuPa5NXaV9pJ4JKw86QdLhGGp
42. FIRH18Iugf3xLFwQEZqKYnblTUs7ftnTgW5r4HH492kCAwEAATANBgkqhkiG9w0BAQQFAAOBgQCs
43. OD02WMoYcMR7Sqdb9oQyk7Nn4rQ5DBgZ5mxGGVzWxBZW/QON+Ir2j4KUjX1jalMvbHa9lnhPQmJi
44. Ued923rza7fvdRG2CDalbW0R3aPd5q0u3akP0/Ejb7z5o88heajCSgfRruvU+ZdOTT3Oe+RBQgw8
45. VuzbLApPnXiehowYuA==
46. </X509Certificate>
47. </X509Data>
48. </KeyInfo>
49. </Signature>
50. </wsse:Security>
51. </soapenv:Header>
52. <soapenv:Body>
53. application specific data/content
54. </soapenv:Body>
55. </soapenv:Envelope>:
|
SOAP 메시지를 보자. 명백히 이것은 전형적인 SOAP 메시지이다. SOAP envelope에는 <soapenv:Header>와 <soapenv:Body> 섹션이 포함되어 있다. WS-Security 섹션은 WS-Security 스팩에 정의된 대로 SOAP 헤더안에 위치해있고 <wsse:Security> 블록(3행-51행)에 있다. <Security> 헤더 블록은 특정 수신자(SOAP 액터)를 목표로한 보안 관련 정보를 어태치하는 메커니즘을 제공한다. 단지 하나의 SOAP 액터가 이 경우 사용되기 때문에 유일한 <Security> 헤더 블록만이 이 메시지에 포함되어있다.
3행에서 SOAP 액터 애트리뷰트는 헤더 엔트리의 수신자(Security soapenv:actor="http://www.jStartcustomer.com/actors#verifier")를 정의한다. SOAP mustUnderstand 애트리뷰트를 "1"로 설정함으로서 서비스 제공자가 SOAP 헤더 엔트리에 프로세스 해야한다는 것을 나타내고있다. SOAP 스팩의 경우 이 애트리뷰트는 "1"로 설정되었기 때문에 수신자가 이 문법에 순응할 수 없고 그러한 문법에 따라 메시지를 프로세스 할 수 없다면 수신자는 메시지 프로세싱에 실패하고 오류를 만든다.
SignedInfo & Digests
4-14행의 <SignedInfo> </SignedInfo>는 서명된 메시지 콘텐트를 나타내고 있다. 디지틀 서명 애플리케이션 관행대로 digest가 보다 빠른 프로세싱을 위해 사용되었다. 이는 산업 표준 관례이고 퍼포먼스와 관련되어 있다. SOAP 메시지의 payload (SOAP Body)는 매우 길고 퍼블릭 키 알고리즘을 전체 메시지에 적용하는 프로세스는 웹 서비스 퍼포먼스에 중대한 영향을 끼친다. 이때 digest가 사용된다. digest는 고정된 길이의 짧은 메시지로서 이것의 디지틀 서명은 빠르게 만들어지고 확인된다. 메시지를 받으면 웹 서비스 디지틀 서명 확인자 클래스는 digest를 계산하고 새롭게 계산된 digest가 보내진 digest와 매치하는지 확인한다.
이 메시지의 Signed Content 부분을 구성하고 있는 엘리먼트를 보자. 5행의 <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>는
서명되고 있는(이경우 digest) 공인된 형식의 정보를 만드는데 사용되는 canonicalization 알고리즘을 확인한다.
XML 문서의 본질과 이와 함께 작동할 프로그래밍 툴 때문에 이 단계가 필요하다. 어떤 경우 XML 문서는 본질적으로는 같은
논리적 문서임에도 미미한 텍스트 상의 차이를 만들어낸다. XML 데이터 구조를 직렬화/직렬해제 할 때 주석이 표현되는 방식과
XML 파서가 라인 한정자를 핸들하는 방식에서 나타나는 작은 변화는 같은 콘텐트의 바이너리 표현을 약간 다르게 만들 수 있다.
디지틀 서명을 확인하는 이 알고리즘이 약간 다른 직렬화된 데이터에 대해 실행한다면 결과는 실패로 끝난다.
이러한 문제를 피하기위해 이 문서는 우선 canonicalization 알고리즘을 사용하여 규범화된 형식으로 변형된다. 이
알고리즘(W3C Exclusive XML Canonicalization Version 1.0 Specification (참고자료) 구현)은 이 문서를 기본적인 규범 문서로 변형한다. 이로서 정확히 비교될 수 있고 정확한 결과를 만들어내는 영속적인 바이너리 표현을 갖게된다.
6행의 <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>은
Signature Method Algorithm알고리즘을 가리킨다. 이것은 canonicalization 알고리즘의 아웃풋을
Signature Value로 변환하는데 사용된다. 우리의 서명 알고리즘은 키 의존 알고리즘(RSA)과 해시
알고리즘(SHA1)의 결합이다. 이 알고리즘은 RSA 스팩의 구현이다. (참고자료).
7행의 <Reference URI="#sign_content_1043176028580">는
레퍼런스 엘리먼트이다. Reference의 선택적인 URI 애트리뷰트는 서명된 데이터 객체를 확인한다. Reference
블록에는 digest를 계산하는데 사용한 알고리즘, 계산된 알고리즘 값, digest 값 계산 이전에 수행된 마지막 변형이
포함되어 있다. 8-9행의 <Transforms> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </Transforms>는 변형 알고리즘을 나타내며 11-12은 digest 알고리즘과 계산된 digest 값을 나타낸다. (<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>FLuQTa/LqDIZ5F2JSaMRHSRuaiQ=</DigestValue>).
우리의 애플리케이션에서 Transform 알고리즘은 위에 언급한 W3C Exclusive XML
Canonicalization 알고리즘이다. digest 계산에 사용된 메소드인 Secure Hash Algorithm
알고리즘은 U.S. Department of Commerce/National Institute of Standards and
Technology's Secure Hash 표준의 일부이다.
15-16행의 <SignatureValue>kGlrrXjKku/WXKxID+JJkEXY+aGNYHc5dy8GwbLFtB5Msll2/MhwdnO9wastJ0gLPzLy3oHL
7A8ggkMkjgAqnLg6PTzM7MdKoIAhe+xRHdOysamGucFJQRMrU+JQ4WATJt0bpdClwJy6mexT
Su48mq1q5rM9YZh61P7UEUKt+EQ=</SignatureValue>에는 서명 값이 포함되어 있는데 이는 실제로 암호화된 digest 값이다. 이 값은 6행 Signature Method Algorithm의 아웃풋이다.
키(Keys)
20
-48행은 키의 개념을 도입하고 있다. 정상적인 읽기 가능한 텍스트 메시지를 인터넷을 통한 전송을 위해 읽기 불가로 만들도록
수학적으로 변형하는데 이 키가 사용된다. 우리의 웹 서비스는 퍼블릭/프라이빗 키(public/private-key) 또는 비대칭
키 암호화 스키마를 사용할 것이다. 이들 키중 하나는 보안이 유지된다. 그것은 바로 프라이빗 키 이다. 우리 애플리케이션에서 웹
서비스 요청자는 문서를 서비스 제공자에 보내기 전에 그의 프라이빗 키로 digest를 서명한다.
20행은 Key Value 블록으로 시작하고 우리가 사용하게 될 네임 스페이스를 확인한다. (<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">). 이 Key Value 블록(<KeyValue> <RSAKeyValue> </RSAKeyValue> </KeyValue>)은 웹 서비스 요청자가 서명을 검사하는데 필요한 키를 얻기위해 필요한 정보를 웹 서비스 제공자에게 제공하는 장소이다. 우리 메시지에서 KeyValue 엘리먼트에는 요청자의 퍼블릭 키가 포함되어 있는데 이것은 서명을 검사하는데 사용될 것이다. 부인 방지 요구사항을 위해 비대칭 RSA 키 기반 접근방식을 사용했다.
RSA 키 스키마를 사용함으로서 메시지는 받은 것과 같은 형태이고 디지틀 인증의 소유자의 서명을 받은 것임을 웹 서비스
제공자에게 확인시킬 수 있다. 재계산된 다이제스트는 솝 메시지에서 해독된 다이제스트를 매치한다면 서비스 제공자는 메시지의
무결성을 확인할 수 있다. 모든 프로세싱이 완료되기 전에 메시지를 기록하여 웹 서비스 제공자는 해당 메시가 메시지를 서명한
사람이 보낸것이고 보내질 때와 같은 형태로 변형되지 않은 채 받았다는 것을 확인할 수 있다
RSAKeyValue 엘리먼트는 두 개의 필드를 갖고 있다:
Modulus
<Modulus>
2sW+eBjx5D2QMyr8ocZIZWNYHGf9zYhB4XWILPCTvhNV7dIe3l8ARepOA1ABFK2OMy
pzb+Rb+nWQeo//yFz/28PmL63kdLiE72qmmQuzuPa5NXaV9pJ4JKw86QdLhGGpFIRH
18Iugf3xLFwQEZqKYnblTUs7ftnTgW5r4HH492k=</Modulus>
|
Exponent
<Exponent>AQAB</Exponent>
|
RSA 스키마는 큰 프라임 숫자를 사용하여 키 쌍을 만든다. Modulus는 두 개의 큰 프라임 숫자의 산물이다. 각 쌍은
Modulus를 공유하지만 각각 특정 Exponent를 갖고 있다. RSA 연구실의 Frequently Asked
Questions About Today's Cryptography, Version 4.1 document (참고자료) 문서에는 Modulus와 Exponent 생성 방법이 설명되어 있다:
서비스 요청자는 그들의 프라이빗 키로 메시지에 디지틀 서명을 한다. 서비스 제공자 측에서 이 서명은 요청자의 퍼블릭 키를
사용하여 확인된다. 서비스 요청자가 프라이빗, 비대칭 키로 메시지에 서명하기 때문에 서비스 제공자는 메시지에 서명을 할 수
있었던 조직 만이 프라이빗 키의 소유자라는 것을 확인할 수 있다.
디지틀 인증
디
지틀 인증은 메시지 전송자를 확인하는데 사용된다. 사용자 ID가 웹과 기업 애플리케이션의 사용자를 확인하는데 사용되는 방식이다.
이 블록의 데이터에 있는 첫 번째 엘리먼트는 인증에 서명한 조직을 확인한다. 이것이 전형적인 인증 권한이다. 우리의 경우 그
정보는 일반 정보로 대체되었다: <X509IssuerSerial>
<X509IssuerName>OU=Java,O=IBM,L=Unknown,ST=Oklahoma,C=US</X509IssuerName>
<X509SerialNumber>0</X509SerialNumber></X509IssuerSerial>
다음은 <X509SubjectName>CN=John Doe</X509SubjectName> 엘리먼트이다. 여기에는 서비스 요청자 이름 (John Doe)과 X.509 인증이 포함되어 있다:
<X509Certificate>
MIIB0TCCAToCAQAwDQYJKoZIhvcNAQEEBQAwTzELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE9rbGFo
b21hMRAwDgYDVQQHEwdVbmsam3duMQwwCgYDVQQKEwNJQk0xDTALBgNVBAsTBEphdmEwHhcNMDIw
OTI1MTAxMTQ4WhcNMDMwOTI1MTAxMTQ4WjATMREwDwYDVQQDEwhKb2huIERvZTCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEA2sW+eBjx5D2QMyr8ocZIZWNYHGf9zYhB4XWILPCTvhNV7dIe3l8A
RepOA1ABFK2OMypzb+Rb+nWQeo//yFz/28PmL63kdLiE72qmmQuzuPa5NXaV9pJ4JKw86QdLhGGp
FIRH18Iugf3xLFwQEZqKYnblTUs7ftnTgW5r4HH492kCAwEAATANBgkqhkiG9w0BAQQFAAOBgQCs
OD02WMoYcMR7Sqdb9oQyk7Nn4rQ5DBgZ5mxGGVzWxBZW/QON+Ir2j4KUjX1jalMvbHa9lnhPQmJi
Ued923rza7fvdRG2CDalbW0R3aPd5q0u3akP0/Ejb7z5o88heajCSgfRruvU+ZdOTT3Oe+RBQgw8
VuzbLApPnXiehowYuA==
</X509Certificate>
|
WS-Security 프로세싱의 마지막 단계는 웹 서비스 요청자의 디지틀 인증을 허가하는 것이다. 디지틀 인증 접근방식을
사용할 때 각각의 웹 서비스 요청자는 공인된 Certificate Authority (CA)가 서명한 디지틀 인증을 갖고
있어야한다. 공인된 인증 권한의 정의는 이 글에서는 다루지 않겠지만 일반적으로 산업계에서 받아들이고 있는 제 3자 인증 권한이
이 역할을 수행한다. 또는 웹 서비스 제공자가 인증 권한 역할을 담당하고 있다. 후자의 접근방식이 사용되면 오픈소스
OpenSSL 툴킷이나 WebSphere Application Server의 IKEYMAN 유틸리티에서 지원하는 기본적인 디지틀
인증을 사용할 것을 권장한다.
우리 애플리케이션을 처음 공개했을 때 고객은 인증 권한의 역할을 수행할 것을 선택했다. 그들은 자신들이 만든 자가 서명한
CA 인증을 만들었다. 모든 웹 서비스 인터랙션 전에 웹 서비스 요청자는 웹 서비스 제공자에게 인증을 제공해야 한다. 인증 권한
역할을 수행하면서 웹 서비스 제공자는 인증에 서명하고 이를 웹 서비스 요청자에게 리턴한다.
앞서 언급한 것 처럼 웹 서비스 요청자는 솝 메시지에 CA 서명된 디지틀 인증을 포함시킨다. 디지틀 서명이 메시지의
무결성을 확인한 후에 이 인증은 메시지에서 추출되고 CA의 퍼블릭 키를 사용하여 유효화 된다. 일단 인증의 유효화가 이루어지면
웹 서비스 요청자는 권한을 받게되고 WS-Security 메시지 부분의 프로세싱이 완료된다.
참고자료
| 
