Metro는 확장이 가능하고 손쉽게 사용할 수 있는 고성능의 웹 서비스 스택으로서, JAX-WS 참조 구현과 Project Tango를 결합합니다. 웹 서비스 상호운영 기술 또는 WSIT라고도 하는 Project Tango는 다른 구현과의 호환을 지원하고 보안, 신뢰성 및 트랜잭션 지원과 같은 서비스 품질(QOS)을 제공하기 위해 수많은 WS-* 표준을 구현합니다. Metro는 Sun Java System Application Server 9.1에 포함되어 있으며, Tomcat과 같은 다른 컨테이너에서도 수행됩니다.
2007년 3월 테크팁 WSIT를 사용하여 웹 서비스 보호하기에서는 웹 서비스 보안에 대한 WSIT의 지원을 중점적으로 다뤘으며 WSIT의 기능을 사용하여 웹 서비스를 보호하는 방법에 대해 소개했습니다. 이어서 2007년 10월 테크팁 Metro와 .NET 간의 상호 운용성 테스트에서는 Metro와 .NET 간의 상호 운용성을 보여 주는 샘플을 소개한 바 있습니다. 이 테크팁은 2007년 3월 테크팁을 토대로 하며, Metro에서 Kerberos 지원을 사용하여 안전한 웹 서비스와 클라이언트를 구축하는 방법에 대해 설명했습니다.
Kerberos 지원은 Metro 1.1용 WSIT를 통해 보안 지원에 추가되었으며, 이후 릴리스의 Metro는 이렇게 추가된 지원을 지속적으로 제공할 것입니다. WSIT에서의 Kerberos 보안에 대한 지원은 WSS:Kerberos Token Profile 1.1 구현을 기반으로 합니다. WS-SecurityPolicy 논리식을 사용하여 Metro에서 Kerberos 보안을 요청하게 되며 이러한 논리식은 "WSIT를 사용하여 웹 서비스 보호하기" 팁에서 다뤘습니다.
이 팁에는 샘플 애플리케이션 패키지가 제공됩니다. 이 팁의 코드 예제는 해당 패키지에 포함된 샘플의 소스 코드에서 따온 것입니다. 이 샘플 애플리케이션은 "WSIT를 사용하여 웹 서비스 보호하기" 팁에서 사용된 것과 비슷합니다. 주요 차이점이라면 이 팁에 나오는 샘플 애플리케이션의 WS-SecurityPolicy 논리식은 Kerberos 토큰을 지정하며 이에 따라 Kerberos V5 프로토콜을 사용하여 메시지가 보호된다는 점입니다.
Kerberos 소개
Kerberos는 MIT(Massachusetts Institute of Technology)에서 Athena 프로젝트의 일환으로 개발한 네트워크 인증 서비스입니다. 이 프로토콜의 이름은 그리스 신화에서 하데스를 보호하는, 머리가 3개 달린 개의 이름 케르베로스(Cerberus)에서 따온 것입니다.
Kerberos는 네트워크 보안에서 취약한 부분을 서버가 아닌 네트워크 연결로 보고 있으며 이에 따라 호스트와 클라이언트 간의 상호 작용을 암호화합니다. Kerberos는 키 배포 센터(KDC)라는 신뢰할 수 있는 제3자를 사용하며 이 센터는 논리적으로 인증 서버(AS)와 티켓 부여 서버(TGS)라는 두 부분으로 구성되어 있습니다. KDC에서는 비밀 키 데이터베이스를 유지합니다. 클라이언트든 서버든 네트워크 내의 각 엔터티는 자신과 KDC에서만 알고 있는 비밀 키를 공유하며, 이 키의 식별 유무를 통해 엔터티의 신원이 입증됩니다.
클라이언트와 서비스와 같은 두 엔터티 간의 통신을 위해 KDC는 엔터티가 상호 작용의 보안 유지에 사용할 수 있는 세션 키를 생성합니다. 그림 1은 서비스에 대한 클라이언트의 액세스를 보호하는 데 사용되는 단계를 보여 줍니다.
그림 1. Kerberos를 사용하여 서비스에 대한 클라이언트 액세스 보호 |
- 사용자가 클라이언트에서 사용자 이름과 비밀번호를 입력합니다. 클라이언트는 비밀번호에 대해 단방향 해시 함수를 실행하여 사용자를 위한 비밀 키를 생성합니다. 클라이언트는 공개되지 않은 문자로 AS에 요청을 보내서 TGT(Ticket Granting Ticket)를 요청합니다. 이 TGT는 나중에 클라이언트에서 특정 서비스에 대한 티켓을 요청하는 데 사용됩니다.
- AS는 해당 클라이언트가 데이터베이스에 있는지를 확인합니다. 클라이언트가 데이터베이스에 존재할 경우 AS는 다음을 포함하는 회신을 생성합니다.
- 사용자의 비밀 키와 함께 암호화된 세션 키. 암호화된 세션 키는 클라이언트와 TGS 간에 비밀로 유지됩니다.
- TGS의 비밀 키를 사용하여 암호화된 TGT.
- 클라이언트가 위의 메시지로부터 암호화된 세션 키를 받아서 해독합니다. 이 세션 키는 나중에 TGS와 통신하는 데 사용됩니다. TGT는 TGS의 비밀 키를 사용하여 암호화되기 때문에 클라이언트는 TGT를 해독할 수 없습니다. 클라이언트는 서비스에 대한 액세스를 요청할 때 다음과 같은 항목으로 구성된 메시지를 TGS에 보냅니다.
- 2단계에서 받은 TGT와 요청된 서비스의 ID.
- 클라이언트 ID와 타임스탬프를 포함하는 인증자.
- 이 인증자는 클라이언트/TGS 세션 키를 사용하여 암호화됩니다.
- 클라이언트로부터 메시지를 받으면 TGS는 비밀 키를 사용하여 TGT를 해독합니다. 그런 다음 TGS에 클라이언트/TGS 비밀 키를 제공합니다. TGS는 이 비밀 키를 사용하여 인증자를 검증합니다. 검증이 성공적으로 이루어지면 TGS는 다음 정보를 클라이언트에 보냅니다.
- 클라이언트 ID, 유효 기간, 클라이언트/서버 세션 키 및 기타 정보를 포함하는 클라이언트-서버 티켓. 클라이언트-서버 티켓은 서비스의 비밀 키를 사용하여 암호화됩니다.
- 클라이언트/서버 세션 키는 클라이언트/TGS 세션 키를 사용하여 암호화됩니다.
- 클라이언트는 클라이언트/서버 세션 키를 해독하여 서비스에 대해 인증을 받을 수 있는 정보를 얻습니다. 클라이언트는 인증을 위해 서비스에 다음을 전송합니다.
- 암호화된 클라이언트-서버 티켓.
- 클라이언트 ID와 타임스탬프를 포함하는 새로운 인증자. 새로운 인증자는 클라이언트/서버 키를 사용하여 암호화됩니다.
- 서비스는 해당 비밀 키를 사용하여 이 티켓을 해독한 후 인증자를 검증합니다. 상호 인증을 사용하지 않을 경우(이 팁의 뒷부분 참조) 서버는 요청된 서비스를 클라이언트에 제공할 준비가 완료됩니다. 또한 이 클라이언트-서버 비밀 키를 사용하여 클라이언트와 서비스 간의 통신을 보호할 수 있습니다.
Kerberos 설정
이 팁은 유닉스 환경에서 Kerberos를 설정한 상태를 기준으로 합니다. 솔라리스나 Ubuntu 리눅스 환경에서 Kerberos를 설정하는 정보가 필요할 경우 다음 문서를 참조하십시오.
윈도우 환경을 사용할 경우 윈도우 서버 에디션 2000 및 2003에서만 Kerberos KDC를 설정할 수 있습니다. KDC는 Active Directory라고 하는 윈도우 전용의 Kerberos 구현과 함께 이러한 에디션에 번들로 제공됩니다. 윈도우에서는 MIT Kerberos KDC를 설치할 수 없습니다. 윈도우 XP 시스템은 윈도우 서버 2003 KDC의 클라이언트로 작동할 수 있습니다. 또한 윈도우용 MIT Kerberos의 클라이언트 모듈을 설치할 수도 있습니다. 자세한 내용은 Kerberos for Windows Release 3.2.2를 참조하십시오. 그런 다음 유닉스 시스템에 설치된 KDC에 대해 이 클라이언트 모듈을 사용하여 인증을 받을 수 있습니다.
Kerberos를 설치한 후 다음과 같이 KDC에 대한 DNS 조회가 제대로 작동하는지 확인합니다.
# nslookup [kdc_hostname] # nslookup [kdc_ip]
예를 들어, 다음 명령을 입력해 볼 수 있습니다.
nslookup ashu07.india.sun.local
이에 대한 응답으로 129.158.229.84와 같은 사용자 시스템의 IP 주소가 표시되어야 합니다. 또한 다음 명령을 입력할 수도 있습니다.
nslookup 129.158.229.84
이 경우 ashu07.india.sun.local과 같이 해당 KDC의 호스트 이름이 표시되어야 합니다. 이것은 DNS 서버가 해당 KDC의 호스트 이름을 제대로 분석할 수 있음을 보여 줍니다.
다음에는 이 단계에서 사용할 서비스 및 클라이언트에 대한 사용자 계정을 추가합니다.
- 다음 명령을 입력하여 Kerberos 계정에 대한 사용자 principal을 만듭니다.
# kadmin.local -q "addprinc admin/admin" [type password]사용자 principal은 Kerberos 계정을 관리하는 데 사용됩니다.
- 다음 명령을 입력하여 Kerberos 클라이언트 및 서비스에 대한 사용자 계정을 추가합니다.
#kadmin.local -p admin/admin
kadmin.local: addprinc -randkey -e
"es128-cts-hmac-sha1-96:normal"
[service_principal]
(Ex of service_principal: websvc/service)
kadmin.local: addprinc -e "aes128-cts-hmac-sha1-96:normal"
[client_principal]
[type password]
(Ex of client_principal: testClient)
kadmin.local: ktadd -e "aes128-cts-hmac-sha1-96:normal "
[service_principal]
kadmin.local: quit
- 작성한 Kerberos 계정에 다음 명령을 입력하여 로그인합니다.
#kinit [client_principal] [type password]
Metro 및 GlassFish를 사용한 Kerberos 보안
Metro 1.1 이상의 릴리스에서는 클라이언트와 서비스 간에 Kerberos V5 프로토콜을 사용하여 SOAP 메시지의 보안 통신이 가능합니다. Kerberos 소개 섹션에서는 클라이언트와 서비스 간에 Kerberos를 사용하여 통신을 보호하는 절차에 대해 설명했습니다. 이제 Metro에서 Kerberos를 사용하여 그러한 절차를 수행하는 방법을 살펴보겠습니다.
- 1단계 및 2단계: 사용자, 즉 클라이언트가
kinit명령 등을 사용하여 해당 계정에 로그인하거나, 클라이언트가 새로운 TGT를 받습니다. - 3단계: 서비스에 액세스하기 전에 클라이언트는 Metro에서 사용된
wsit-client.xml이라는 구성 파일에서 서비스 principal의 이름을 액세스한 후 KDC로부터 서비스 principal에 대한 티켓을 요청합니다.wsit-client.xml파일에 대한 설명은 이 팁의 뒷부분에 나와 있습니다. - 4단계: 클라이언트가 갖고 있는 자격 증명이 유효할 경우 KDC는 서비스에 대한 티켓 및 서비스에 대해 사용할 비밀 키를 클라이언트에 제공합니다.
- 5단계: 이전 단계의 모든 통신은 SOAP 메시지 외부에서 이루어집니다. 그러나 이 시점에서는 통신이 SOAP 메시지를 사용하여 수행됩니다. 클라이언트는 서비스에 대한 티켓과 비밀 키를 받은 후 SOAP Security 헤더의
BinarySecurityToken요소에 티켓과 인증자를 포함시켜 서비스에 전송합니다. 또한 클라이언트는 해당 세션에 대한 비밀 키를 사용하여 SOAP 메시지의 모든 비공개 정보를 보호합니다. - 6단계: 서비스가 티켓을 해독하여 세션 키를 받고 인증자를 검증합니다. 인증자가 성공적으로 검증되면 서비스는 비밀 키를 사용하여 메시지의 보호된 부분에 대한 무결성이나 기밀성을 검증합니다.
서비스에 대해 Kerberos 토큰 기반의 보안 정책 만들기
WSIT를 사용하여 웹 서비스에 대한 보안을 활성화하려면 서비스에 대한 WSDL(Web Services Definition Language) 파일에 보안 정책을 생성하여 첨부해야 합니다. 일반적으로, 웹 서비스 보호를 위해 생성해야 하는 보안 정책은 바인딩 레벨 정책과 작업 레벨 정책의 두 가지 유형이 있습니다. 이러한 정책에 대한 팁은 WSIT를 사용하여 웹 서비스 보호하기를 참조하십시오. 이 팁에는 Kerberos 토큰을 사용하도록 지정을 변경하기 위해 필요한 바인딩 레벨 정책이 나와 있습니다. 여기서 Kerberos 토큰은 위의 5단계에서 설명한 것처럼 SOAP Security 헤더의 BinarySecurityToken 요소에 포함되어 있는 티켓과 인증자입니다.
<wsp:Policy wsu:Id="IFinancialService_policy">
<wsp:ExactlyOne>
<wsp:All>
<wsaws:Us"http://www.w3.org/2006/05/addressing/wsdl"/>
<sp:SymmetricBinding>
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<sp:KerberosToken sp:IncludeToken=
"http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Once">
<wsp:Policy>
<!--<sp:RequireDerivedKeys />-->
<sp:WssGssKerberosV5ApReqToken11/>
</wsp:Policy>
</sp:KerberosToken>
</wsp:Policy>
</sp:ProtectionToken>
...
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128/>
</wsp:Policy>
</sp:AlgorithmSuite>
</wsp:Policy>
</sp:SymmetricBinding>
...
<sc:KerberosConfig xmlns:sc=
"http://schemas.sun.com/2006/03/wss/server"
loginModule="KerberosServer"/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<sp:KerberosToken> 요소를 살펴보겠습니다. 이 요소는 Kerberos 토큰 논리식으로서, 서비스에 대해 클라이언트가 인증을 받고 메시지를 보호하기 위해 클라이언트로부터 Kerberos 토큰이 필요하다고 가정합니다. WssGssKerberosV5ApReqToken11 요소는 The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2, RFC4121에 지정된 대로 메시지에 GSS Kerberos v5 토큰이 사용됨을 지정합니다.
또한 <sc:KerberosConfig> 요소를 살펴보겠습니다. 이 요소는 Kerberos에서 사용할 JAAS(Java Authentication and Authorization Service) 로그인 모듈의 이름을 지정합니다. 이 JAAS 로그인 모듈(이 예제에서는 KerberosServer)은 이 팁의 샘플 코드 실행하기에서 설명한 것처럼 <AS_HOME>/domains/domain1/config/login.conf 파일에 지정됩니다.
이 샘플에 사용된 작업 레벨 정책은 "WSIT를 사용하여 웹 서비스 보호하기" 팁에서 사용된 것과 동일합니다. 이 작업 레벨 정책은 본문과 주소 지정 헤더가 서명되어야 하고 본문이 암호화되어야 하도록 지정합니다.
웹 서비스 배포하기
WSIT 보안이 구현된 웹 서비스는 일반 JAX-WS 기반 웹 서비스와 동일한 방식으로 빌드하고 배포할 수 있습니다. JAX-WS 기반의 웹 서비스를 빌드하는 방법에 대한 자세한 내용은 JAX-WS를 사용하여 웹 서비스 개발하기 팁을 참조하십시오.
클라이언트 생성하기
웹 서비스를 배포하면 클라이언트 프로그램에서 해당 서비스에 액세스할 수 있습니다. JAX-WS 기반 웹 서비스에 액세스하는 클라이언트의 빌드 단계는 JAX-WS를 사용하여 웹 서비스 개발하기 팁에 설명되어 있습니다. 하지만 WSIT를 통해 보호된 웹 서비스에 액세스하는 클라이언트를 빌드하려면 클라이언트에 대한 보안을 구성해야 합니다.
클라이언트에 대한 보안 정보 구성하기
클라이언트에 대한 보안을 구성하려면 wsit-client.xml이라는 파일에 보안 관련 정보를 지정해야 합니다. WSDL 문서를 포함하는 이 파일은 클라이언트에서 사용할 로컬 보안 정책과 서비스 WSDL로부터 받은 정책을 지정합니다.
본 팁과 함께 제공되는 샘플 애플리케이션 패키지에는 독립적으로 작동하는 클라이언트인 FinancialServiceClient.java가 제공됩니다. 다음은 wsit-client.xml 파일에서 클라이언트에 대한 보안 구성을 보여 줍니다.
<wsp:Policy wsu:Id="ClientKerberosPolicy"
xmlns:sc="http://schemas.sun.com/2006/03/wss/client"
xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy"
xmlns:scc="http://schemas.sun.com/ws/2006/05/sc/client">
<wsp:ExactlyOne>
<wsp:All>
<sc:KerberosConfig wspp:visibility="private"
loginModule="KerberosClient"
servicePrincipal="websvc/service@INDIA.SUN.COM"
credentialDelegation="true" />
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
이 샘플 로컬 정책에는 클라이언트에서 Kerberos가 사용할 JAAS 로그인 모듈의 이름을 지정하는 loginModule 속성에 지정됩니다. 본 예제에서 이 JAAS 로그인 모듈은 KerberosClient이며 <AS_HOME>/domains/domain1/config/login.conf 파일에 지정됩니다. 이 팁의 샘플 코드 실행하기 섹션을 참조하십시오. servicePrincipal 속성은 클라이언트가 KDC로부터 티켓을 요청해야 하는 서비스 principal의 이름을 지정합니다. credentialDelegation 요소는 클라이언트 자격 증명이 서비스에 위임되어야 하는지를 나타내며 이 예제에서는 위임되어야 합니다. 자격 증명 위임은 서버에서 클라이언트 대신 다른 보안 컨텍스트를 개시하려 할 경우에 유용하며 다중 계층 환경에서의 단일 로그인에 중요한 기능입니다.
샘플 코드 실행하기
이 팁에는 샘플 패키지가 제공됩니다. 샘플을 설치하고 실행하려면 다음 단계를 수행합니다.
- JDK 6이 없으면 Java SE Downloads 페이지에서 JDK 6을 다운로드하여 설치합니다. Metro에서 Kerberos 지원은 JDK 6 이상 릴리스에서만 작동합니다.
- 자바 EE 5 SDK 업데이트 4가 없으면 Java EE Downloads 페이지에서 자바 EE 5 SDK 업데이트 4를 다운로드하여 설치합니다.
- Metro Project 사이트에서 Metro 1.1을 다운로드한 후 WSIT Documentation 페이지의 설명에 따라 설치합니다.
WSIT_HOME시스템 등록 정보를 다음과 같이 설정합니다.<AS_HOME>/domains/domain1/config/domain.xml파일을 텍스트 편집기에서 엽니다. 여기서<AS_HOME>은 자바 EE 5 SDK 업데이트 4가 설치된 디렉토리입니다.- 파일에 다음과 같은 JVM 옵션을 추가합니다.
<jvm-options>-DWSIT_HOME=${com.sun.aas.installRoot} </jvm-options> <jvm-options> -Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true </jvm-options> <jvm-options> -Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true </jvm-options>
- Kerberos에 대해 사용할 JAAS 로그인 모듈을 다음과 같이
<AS_HOME>/domains/domain1/config/login.conf파일에 지정합니다.KerberosClient { com.sun.security.auth.module.Krb5LoginModule required useTicketCache=true; }; KerberosServer { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="/etc/krb5.keytab" doNotPrompt=true storeKey=true principal="websvc/service@INDIA.SUN.LOCAL"; };로그인 모듈의 이름은
KerberosClient및KerberosServer대신 아무 이름이나 지정할 수 있습니다. 이러한 이름은 WSDL 파일의<sc:KerberosConfig>논리식 및wsit-client.xml파일에서 참조해야 합니다.또한
KerberosServer의 principal을 사용자가 작성한service_principal로 수정합니다. - 팁에 대한 샘플 패키지를 다운로드한 후 컨텐츠의 압축을 풉니다. 이제 새로 생성된
<sample_install_dir>/wssec-kerb디렉토리를 볼 수 있을 것입니다. 여기서<sample_install_dir>은 샘플 패키지를 설치한 디렉토리입니다. wssec-kerb/src/fs디렉토리로 변경합니다.build.properties파일에서java.home을 해당 시스템에서 JDK가 설치된 위치로 설정합니다.glassfish.home은 자바 EE 5 SDK 업데이트 4가 설치된 디렉토리로 설정합니다.- 다음 명령을 입력하여 샘플을 실행합니다.
ant run-sample
다음과 같은 응답이 나타나야 합니다.
balance=1,000,000 Acknowledgement : successfully deposited.
<AS_HOME>/domains/domain1/logs디렉토리에 있는 애플리케이션 서버에 대한 로그 파일에서 메시지 흐름을 볼 수 있습니다.
저자 정보
Ashutosh Shahi는 썬마이크로시스템즈 Web Services Security Group의 일원으로서, 현재 썬의 Metro 웹 서비스 스택에서의 보안과 관련된 WS-* 기술 구현에 참여하고 있습니다. 썬에 입사하기 전에는 Apache의 오픈 소스 SOAP 엔진인 Apache Axis의 개발을 담당했었습니다.
이 글의 영문 원본은
http://blogs.sun.com/enterprisetechtips ··· services
에서 보실 수 있습니다.
--------------------------------------------------------------------------------------------------------------------
|
GlassFish에 연결하여 참여
GlassFish에 참여하여 iPhone 경품의 주인공이 되어 보십시오. 본 행사는 2008년 3월 23일까지 진행됩니다. 지금 바로 참여하십시오.
"Java EE" 카테고리의 다른 글
- JAXR (JAVA API FOR XML REGISTRIES) (댓글 1개 / 트랙백 0개) 2005/05/18
- JAVA 트랜잭션 API 소개 (댓글 1개 / 트랙백 0개) 2005/03/23
- 환경 엔트리를 이용해서 배포의 사용자 정의하기 (댓글 2개 / 트랙백 0개) 2003/12/24
- EJB 세션 빈(Session Bean)을 모델 파사드(Model Facade)로 사용하기 (댓글 4개 / 트랙백 0개) 2007/04/10
- 레슨: JavaBeans의 개념 (댓글 0개 / 트랙백 0개) 2008/02/20
- Model Facade 사용하기 (댓글 4개 / 트랙백 0개) 2006/12/22
- 자바 기술을 이용한 AJAX의 활용 (댓글 1개 / 트랙백 0개) 2005/12/27
- JAVAMAIL API를 사용해서 HTML 이메일 보내기 (댓글 1개 / 트랙백 0개) 2004/04/28
- Java에서 RESTful 웹 서비스 구현하기 (댓글 1개 / 트랙백 0개) 2007/12/04
- 스키마 검증 프레임워크 (댓글 1개 / 트랙백 0개) 2005/11/22
댓글을 달아 주세요