모든 주요 웹 서비스 스택들은 WS-Security 및 관련된 웹 서비스 보안 표준에 대한 어느 정도 수준의 지원을 제공한다. 이 시리즈에서 다루는 세 가지 오픈 소스 스택들은 — Apache Axis2, Sun/Oracle Metro 및 Apache CXF — 모두 이러한 표준에 대한 매우 높은 수준의 지원을 제공한다. 하지만, 이러한 지원은 보안 운영과 스택들이 런타임 보안 매개변수로 구성되는 방법 둘 다를 비롯하여 수많은 방식에서 엄청나게 다르다.

중요한 차이점의 영역 중 하나는 보안 구현의 완료성 및 정확성과 관련이 있다. WS-Security 및 WS-SecurityPolicy는 키 및 인증서들의 다른 유형, 알고리즘 세트, 보안 토큰 및 스펙 서명/암호화를 비롯한 보안 구성들의 변형을 많이 허용한다. WS-Trust 및 WS-SecureConversation은 더 나아가 옵션의 숫자를 늘린다. 가능한 많은 구성을 통해 어느 웹 서비스 스택도 모두 테스트할 수는 없다. 분리할 때에 가능한 각 옵션 값을 테스트하는 것조차 어렵고, 대부분의 스택들은 시도하지 않는다.

이 기사에서는 먼저 웹 서비스 스택들 사이의 보안 상호 운용성의 문제점에 대해 자세히 학습할 것이다. 그 후에 지난 여러 기사들과 이 시리즈의 기사에 대한 필자의 연구를 기반으로, Axis2, Metro 및 CXF가 정확성과 사용성의 몇 가지 측정으로 어떻게 비교되는지 설명한다.

보안 상호 운용성

보안 표준들은 포괄적인 테스팅에 대한 너무 많은 옵션들의 조합을 제공한다. 많은 표준들은 예제의 방식으로 약간 제공하고 테스트 세트의 측면에서 아무것도 제공하지 않기 때문에, "표준"에 대한 적합성은 종종 의견과 추측에 따라 달려있다. 결과적으로 특정 표준을 지원하도록 요구하는 스택들은 지원을 거의 광범위하게 확인하지 않는다.

각 스택은 표준에 대해 테스트를 시도하는 것이 아니라 자체적인 테스팅을 위해 제한된 수의 보안 구성을 사용하며, 마찬가지로 다른 스택들과의 상호 운용성을 테스트하는 면에서 훨씬 더 제한된 수의 구성을 사용한다. 그 외에도 각 스택의 개발자들은 보안 구성이나 상호 운용성 문제에 직면하는 사용자들로부터 버그 보고서에 응답한다. 표준의 복잡한 세트에 대한 이렇게 제한된 테스팅은 메인스트림에 속하지 않은 다른 것을 시도하면 종종 문제가 발생할 것이라는 점을 의미한다. 이 시리즈의 기사들에서 보안 논의와 성능 비교에 대해 테스트된 상대적으로 제한된 수의 보안 구성에서조차도 이 유형의 몇 가지 문제점들을 발견했다.

웹 서비스 보안 코드의 품질을 개선하는 노력이 어느 정도 진행되었으며, 여기에는 업계 전반 조직의 작업과 벤더 구동 상호 운용성 테스팅이 포함된다. 특히 후자는 스택들 사이에 호환성의 기본 레벨을 정립하는 데 유용하였지만, 테스트된 구성의 숫자가 적어 혜택은 제한되었다.

WS-I 기본 보안 프로파일

시작부터 SOAP 웹 서비스 스펙은 구현자와 사용자들에게 선택을 많이 제공했다. 이는 부분적으로 설계에서 진행되었다. 다른 경우들은 표준 면에서 간과하여 생겨났다. 예상되는 작동들이 충분히 자세하게 지정되지 않았으므로, 구현자들은 무엇이 수행되어야 하는지 추측해야 한다. 선택이 너무 많아서 생긴 문제는 구현자들이 모든 가능한 조합을 완전히 테스트하는 자원이 부족하여, 웹 서비스 스택들에서 일부 선택 세트는 훌륭하게 지원하고, 일부는 불량하게 지원하며, 또 다른 일부는 여전히 아예 지원하지 않는 것이다. 이 상황은 상호 운용성에 대한 주요 문제점을 생성한다. 왜냐하면 다른 스택들이 동일한 선택을 지원하도록 보장하지 않기 때문이다.

선택 과부하는 SOAP의 초기에 "우수 사례" 접근방식을 정의하여 가능한 구성의 수를 제한하는 특정 용도로 업계 전반의 그룹이 생성되는 큰 문제였다. 웹 서비스 상호 운용성 조직(WS-I)인 이 그룹은 사용하거나 방지하는 특정 선택이 필요한 프로파일의 수를 제작했다(참고자료 참조). 이러한 프로파일을 통해 WS-I는 웹 서비스 스택들의 현재 3세대의 모양을 만드는 데 주된 영향을 미쳤다.

보안은 프로파일에서 WS-I가 다루는 영역 중 하나이다. WS-I Basic Security Profile 버전 1.1(BSP 1.1이라고 함)은 보안 영역에서 현재 기본 문서이다. 이 문서는 광범위한 요구사항들이 포함되지만, WS-I의 초점을 유지하는 면에서 이러한 대부분의 요구사항들은 일반 사용자 보안 구성 대신에 웹 서비스 스택 구현을 처리한다. BSP 1.1은 WS-SecurityPolicy에서 WS-Security 구성을 아예 처리하지 않지만, 그 몇 가지 요구사항들은 WS-SecurityPolicy 용어로 변환될 수 있다.

디지털 서명을 사용할 때에, BSP 1.1에서는 주석과 불필요한 컨텍스트 정보를 무시하는 W3C Exclusive Canonicalization Recommendation인 XML 캐논 형식의 알고리즘을 따라야 한다(참고자료 참조). 이 알고리즘은 선택사항이 없으면 WS-SecurityPolicy가 가정하는 기본값이므로, 이 요구사항들에 부합하기 위해 필요한 것은 다른 캐논 형식의 알고리즘(<sp:InclusiveC14N> 등)을 지정하지 않는 것이다.

또한 BSP 1.1은 WS-SecurityProfile에서 정의한 알고리즘 세트 값을 제한하는 서명과 암호화 모두에 대한 다른 요구사항들도 일부 추가하지만, 이러한 사항들은 기본적으로 TripleDes, Aes128 또는 Aes256 암호화 및 SHA1 소화를 사용하여 이에 대한 선택을 제한한다(WS-SecurityPolicy에서 제공하는 Aes192 암호화 및 SHA256 소화 옵션만 제외). 다른 BSP 권장사항들은 얼마나 다양한 보안 토큰들을 참조하고 사용하는지 제한한다.

WS-I BSP는 웹 서비스 보안 구현에 걸친 상호 운용성에는 물론 기여했지만, 이러한 사소한 점들 외에 보안 구성 선택의 복잡도를 줄이는 방향으로는 아무 일도 하지 않았다. WS-SecurityPolicy 구성을 더 구체적으로 지향하는 BSP의 업데이트된 버전은 현대식 정책 기반 구성을 사용하여 보안 아키텍트에 대한 우수 사례를 정립하는 데 매우 유용할 것이다. 하지만 WS-I는 이러한 업데이트에 관심을 보이지 않았다.

상호 운용성 테스트

스택들에 걸친 벤더 구동 상호 운용성 테스팅은 웹 서비스 보안 구현의 품질을 개선하는 측면에서 더 중요한 요인이었다. Microsoft®는 이 영역에서 하나의 원동력이 되어, 다른 웹 서비스 스택들(상업용 및 오픈 소스 모두)의 개발자들이 그들의 코드와 Microsoft 구현 사이에 다양한 시나리오를 테스트하는 면에서 참여하도록 초대되는 캠퍼스에서 "interoperability plug-fests"의 시리즈를 주관하였다(참고자료 참조). 보안은 plug-fests의 주요 초점이었다.

이 상호 운용성 테스팅은 스택들 사이에 호환성의 기본 레벨을 정립하는 데 유용하였지만, 테스트된 구성의 숫자가 적어 혜택은 제한되었다. Microsoft 구현을 통한(실제 표준을 기반으로 하는 테스트 세트 대신에) 상호 운용성에 대한 초점은 제한점이 되었지만, 이는 실용적인 측면에서 열 두 개 이상의 스택들 사이에 완전한 교차 호환성 테스트보다 처리하기에 훨씬 더 간편하다.

위로

보안 문제점 및 제한조건

이 기고 시리즈에서 세 가지 웹 서비스 스택들에서 다양한 보안 구성을 테스트하여 각 스택의 몇 가지 문제점들을 발견했다. 제한된 상호 운용성 테스팅(클라이언트에 스택 한 개와 서버에 또 다른 한 개를 사용하여 WS-SecureConversation 테스트를 위해서만 시도됨)은 더 많은 문제점들을 드러냈다. 하나의 스택인 Apache Axis2의 경우에 심각한 성능 문제도 발견했다. 이러한 문제들은 각 스택의 개발자들에게 보고되었으며, 일부는 최신 릴리스에서 수정되었다. 이 섹션에서는 이러한 기사에서 수행한 테스팅에 대해 세 개의 스택들의 현재 상태를 요약할 것이다.

Axis2 문제점

Axis2와 관련되어 발견한 문제들은 WS-SecureConversation 정책 처리를 포함하며, 여기에서 부트스트랩 정책 정의가 운영에서 완전히 무시되어 나타난다. 이는 Axis2가 WS-SecureConversation 지원에 대해 사전 준비된(canned) 구성을 사용하는 것을 의미하기 때문에, 동일한 구성을 사용하는 다른 스택들과의 호환만 가능하다.

보안 런타임의 측면에서 Axis2는 대칭 바인딩의 클라이언트측 처리와 관련하여 주요 문제가 있다("클라이언트 인증 없는 WS-Security"에서 논의됨). 클라이언트는 요청이 더 많이 작성될수록 점진적으로 더 느리게 실행한다. 문제의 점진적인 성향으로 인해 필자는 이를 성능 문제라기보다는 하드 버그라고 생각한다.

Axis2 보안 처리는 시간 보안을 사용하는 일관적으로 느린 운영으로도 번거롭게 된다(일부 결과를 보려면"CXF 성능 비교" 참조). 이 성능 문제는 Axis2로 사용하는 AXIOM 오브젝트 모델과 보안 코드로 사용하는 표준 DOM 사이에 비호환성으로부터 나타나므로, AXIOM이 전체 DOM 호환성을 제공하도록 향상되지 않는 한, 그 때까지 문제들은 계속될 가능성이 있다.

마지막으로, 필자의 견해로는 Axis2는 핵심 웹 서비스 엔진(실제 Axis2 코드)과 보안 코드(Rampart 및 Rahas 보안 모듈) 사이에 연결이 끊어져서 골치거리가 되는 경향이 있다. 이전에 필자를 포함한 우리는(Axis2 커미터들) 핵심 코드에서부터 보안 코드를 분리하도록 결정하여, 이러한 컴포넌트들이 개별적으로 향상되고 릴리스되도록 허용했다. 불행히도 이는 보안 코드를 선택적 컴포넌트로 취급되는 결과가 나타났으며, Axis2 릴리스는 현재 시점의 Rampart 릴리스와 작업하지 않도록 만들어졌다. 최근의 Axis2 1.5.2 릴리스가 한 예이다. 2진 배포는 보안 처리에 필수적인 JAR 파일을 누락하여, Rampart와 작업하도록 만드는 간편한 방법이 없다. 이는 현재 Axis2 1.5.3 릴리스에서는 수정되었지만, 공식적인 릴리스는 보안 지원을 작동하지 않고 제공될 것이라는 바로 그 사실은 연결이 끊어지는 것을 보여준다.

이 기사들을 쓰면서 필자가 발견한 중요한 Axis2 문제들 중 어느 하나도 현재 최신 Axis2와 Rampart 릴리스에서 수정되지 않았다.

Metro 문제점

이 시리즈의 기사에 나온 테스트에서 Metro와 관련된 일부 중요한 문제점들이 드러났다. 가장 큰 문제는 Metro의 메시지 본문 서명의 처리이다. 정책에 <sp:OnlySignEntireHeadersAndBody/> 어설션이 포함되면 모두 문제가 없지만, 이 어설션을 사용하지 않는다면 Metro는 본문 요소 그 자체가 아니라 본문의 내용을 잘못 서명한다. 서명을 올바르게 처리하는 스택들은 Metro가 이러한 방식으로 서명한 메시지를 거부할 것이다.

또한 Metro는 "WS-Trust and WS-SecureConversation"에 사용된 WS-SecureConversation 정책을 위반했다. 이 경우에 문제는 정책이 보안 토큰 서비스(STS)와 서비스와의 실제 대화 간에 부트스트랩 메시지 교환을 위해 다른 알고리즘 세트를 사용했다는 점이다. Metro는 이를 무시했으며 둘 다에 하나의 알고리즘 세트만 사용했다. 이는 두 개의 다른 알고리즘 세트를 실제로 사용할 이유가 거의 없기 때문에 서명 문제점만큼 중대한 문제는 아니지만, 여전히 오류이다.

마지막으로 Metro는 또한 "Understanding WS-Policy"에서 보고한 단방향 암호화 또는 서명의 사용과 관련한 문제점들도 있다. 이러한 문제점들은 현재 최신 Metro 릴리스에서 수정되지 않았다.

CXF 문제점

다른 스택들과 마찬가지로 이러한 기사들에서 테스트하면서 일부 CXF 문제들을 발견했다. 거의 모든 경우에 문제점들은 기사가 발행되기 전에 새 CXF 릴리스에서 수정되었다. 하나의 예외는 "Understanding WS-Policy"에서 보고한 단방향 암호화 또는 서명의 사용과 관련한 문제점에 대한 것이다. — 이는 이제 CXF 2.3.1 릴리스에서 수정되었다.

위로

스택 비교

보안 지원에서 웹 서비스 스택들을 순위 지정하려는 시도는 각 스택이 강점과 약점을 둘 다 보유하고 있기 때문에 필연적으로 매우 주관적일 것이다. 균형 잡힌 평가를 제공하는 노력의 일환으로 순위 지정 요인을 네 가지로 나누었으며, 각 스택에 대해 전통적인 1에서 10까지(가장 나쁨에서 가장 좋음) 범위의 숫자로 된 순위를 지정했다.

• 정확성: 구현 오류가 얼마나 많이 알려졌으며, 그 오류들은 어느 정도로 심각한가?
• 완료성: 보안 구현은 어느 정도로 완료되었는가?
• 성능: 얼마나 많은 오버헤드가 보안 처리를 추가하는가?
• 사용성: 보안 코드를 구성하는 것이 어느 정도로 간편한가?

정확성

Axis2는 일부 중요한 문제가 있으며, 핵심 코드와 Rampart 보안 모듈 사이에 연결이 끊기는 것은 우려할 문제이지만, 전체적으로 매우 견고한 것으로 보인다. 점수: Axis2 — 6.

Metro는, 특히 <sp:OnlySignEntireHeadersAndBody/> 없이 사용할 때에 서명의 잘못된 처리 면에서 어느 정도 주요한 문제점들이 있다. 그럼에도 불구하고 Axis2와 같이 대체로 매우 견고한 것처럼 보이며, 보안 코드의 기본 릴리스로의 통합은 Axis2를 사용하는 것보다 완전히 실패할 경향이 줄어든다. 점수: Metro — 7.

CXF는 상대적으로 사소하다고 알려진 문제들만 있으며, 문제에 대한 빠른 응답과 신속한 릴리스 사이클은 문제가 발견되면 대체로 즉시 수정된다는 것을 의미한다. 점수: CXF — 8.

이제 공평하게 하기 위해 이러한 기사들의 코스에서 직접적으로 경험한 문제들만 고려하였다. 버그 추적 시스템을 스택들에 대해 확인하면 다른, 잠재적으로 더 중요한 문제들이 드러날 것이다. 이러한 사항들을 살펴볼 때에 주의를 기울여야 한다. — 보고된 일부 문제점들은 사용자 오류를 유발할 수 있다. — 하지만, 특정 스택에서 표준화를 고려하고 있다면 해볼 만한 연습이다. 세 가지 스택들의 버그 추적 시스템에 대한 내용은 참고자료를 참조하자.

완료성

세 개의 모든 스택들은 모든 주요 보안 표준들에 대한 지원을 제공한다. 하지만, Axis2 지원은 최소한 두 가지 면으로 제한된다. WS-Policy의 경우 Axis2 코드 생성은 2007년에 릴리스된 표준 W3C 버전이 아니라 2004년에 제출된 구형 버전으로만 작동한다. WS-SecureConversation의 경우, Axis2는 "사전 준비된(canned)" 구성을 구현하여, 제공하는 정책 구성을 무시한다. 점수: Axis2 — 6; Metro — 7; CXF — 7.

성능

Axis2는 보안 성능 순위 지정에서 보면 분명히 뒤처진다. 메시지 레벨 보안 처리의 모든 형식에서 Metro나 CXF 중 하나보다 훨씬 더 많은 처리 오버헤드를 생성한다. Metro는 CXF보다 전체적으로 조금 더 빠르기 때문에, 이 요인으로 인해 필자의 점수는 Axis2 — 4; Metro — 8; CXF — 7이다.

사용성

Axis2의 보안 구성은 다소 골치거리이다. 이는 클라이언트 측에서 서비스 WSDL로 런타임 매개변수를 임베드하거나 클라이언트 코드로 직접 매개변수를 구성해야 한다. 어느 방식으로나 클라이언트 코드에서 실제로 보안 처리를 활성화해야 한다. 서버 측에서 생성된 services.xml 파일을 수정하여 런타임 매개변수를 포함하고 보안 처리를 활성화해야 한다. Axis2는 또한 정책 구성에서 이해되지 않는 것들은 조용히 무시하는 경향이 있다. 점수: Axis2 — 5.

Metro는 아마 Axis2보다는 작업하기에 조금 더 간편하지만, 이는 런타임 매개변수를 항상 서비스 WSDL에 추가해야 한다(또는 최소한 클라이언트 측에서 매개변수를 정의하는 개별 문서를 참조한다). 필자가 생각하기에 이는 부적절하다. 왜냐하면 WSDL은 발행된 서비스 계약을 표현해야 하기 때문이다. Metro는 또한 NetBeans/Glassfish 번들 외부에서 보안 기능을 구성하고 사용하는 것에 대한 약간의 문서를 제공한다. 마지막으로 필자의 경험 상, 구성 문제가 있을 때에 표시되는 오류 메시지는 모호한 경향이 있어, 원인을 추적하기에 어렵게 만든다. 점수: Metro — 6.

CXF는 구성에 대한 가장 명확한 접근방식을 보유하여, 일반적으로 클라이언트와 서버 둘 다에서 런타임 보안 매개변수에 대해 개별 파일들을 사용한다. 모두 직접 Spring을 사용하여 구성하거나 코드에서 구성하는 옵션도 있다. 기본 구성 문제점을 넘어서도 CXF는 또한 WSDL에서 외부 정책 참조를 지원하며, 이는 전사적으로 보안 정책을 표준화하려는 조직의 중요한 기능이다. 마지막으로, CXF는 정책이 완전히 지원되지 않음을 알려주는 경고 메시지를 생성하여, 지원되지 않은 정책 컴포넌트에 대해 우수한 처리를 보유한 것처럼 보인다. 점수: CXF — 8.

표 1에 필자가 지정한 순위를 요약했다.

이러한 순위들은 확정된 것으로 의도하지 않았으므로, 스택의 자체적인 사용에 대해 결정을 내리는 측면에서 사용하는 경우에 필자의 타당성을 검토하고 스스로 결정하도록 하자. 또한 순위는 기본 오픈 소스 프로젝트에만 적용된다. 오픈 소스 버전을 기반으로 하는 상업용 스택들은 자체적인 보안 코드와 다른 확장을 사용할 수 있다. 순위의 어느 부분을 적용할 수 있는지 보려면 상업용 코드와 오픈 소스 기반 사이의 차이점에 대해 살펴봐야 할 것이다.

위로

마무리하기

이 시리즈에 지금까지 살펴 본 세 가지의 오픈 소스 웹 서비스 스택들은 모두 보안 기능을 위한 훌륭한 지원을 제공한다. 각 스택은 보안 영역 측면에서 어느 정도 강점과 약점이 있으며, 이 기사에서는 최근의 여러 기사 모음에 걸쳐서 이러한 세 가지로 작업하는 필자의 경험을 기반으로 이들이 어떻게 비교되는지의 요약을 살펴보았다.

이 시리즈에서 다음 기사는 다른 방향을 취하여, WSDL 서비스 정의의 구조를 살펴보고 WSDL을 확인하고 이를 권장된 우수 사례 양식으로 변환하는 도구를 개발한다.

참고자료

교육

• Axis2: Axis 2는 Apache Software Foundation의 오픈 소스 웹 서비스 스택이다.
  
  
• CXF: CXF는 Apache의 또다른 오픈 소스 웹 서비스 스택이다.
  
  
• Metro: Metro는 JAXB 2.x 및 JAX-WS 2.x Java 표준의 최신 참조 구현을 통합하는 오픈 소스 웹 서비스 스택이다.
  
  
• Web Services Interoperability Organization: WS-I는 기본 웹 서비스 및 보안 기능 모두에 대한 우수 사례를 설정하는 데 도움을 주었다.
  
  
• Exclusive XML Canonicalization: 디지털 서명의 경우, BSP 1.1은 이 W3C Recommendation에 지정된 캐논 형식의 알고리즘을 요구한다.
  
  
• Web Services Interoperability Plug-Fest: Microsoft가 조직한 Plug-Fests는 웹 서비스 스택들 사이에 상호 운용성을 촉진하도록 도움을 주었다.
  
  
• 버그 추적:
  • Axis2 Jira는 핵심 Axis2 코드에 대한 버그 보고서를 추적하는 동안, Rampart Jira는 특히 보안 처리와 관련되는 버그를 추적한다.
  • CXF Jira는 일반 WS-* Components 카테고리 아래에 포함된 보안 처리로 모든 CXF 버그를 추적한다.
  • Metro Issue Tracker는 WSIT 컴포넌트 아래에 보안 및 다른 WS-* 문제점들로 모든 Metro 버그를 추적한다.
  
  
• 기술 서점에서 다양한 기술 주제와 관련된 서적을 살펴보자.
  
  
• developerWorks Java 기술 영역: Java 프로그래밍과 관련된 모든 주제를 다루는 여러 편의 기사를 찾아보자.
  
  

토론

• My developerWorks 커뮤니티에 참여하자. 개발자가 이끌고 있는 블로그, 포럼, 그룹 및 Wiki를 살펴보면서 다른 developerWorks 사용자와 의견을 나눌 수 있다.
  
  

필자소개

Dennis Sosnoski는 Java 기반 SOA 및 웹 서비스를 전문으로 하는 컨설턴트 및 트레이너이다. 30년 이상의 전문 소프트웨어 개발 경력을 가지고 있으며 최근 10여년 동안에는 서버측 XML 및 Java 기술에 주력하고 있다. 오픈 소스 JiBX XML 데이터 바인딩 프레임워크 및 연관된 JiBX/WS 웹 서비스 프레임워크의 책임 개발자이자 Apache Axis2 웹 서비스 프레임워크 개발에도 참여하고 있다. JAX-WS 2.0 및 JAXB 2.0 스펙의 전문가 그룹에도 참여했다. Java 웹 서비스 시리즈에 대한 자료는 Dennis의 SOA 및 웹 서비스 교육 강의를 바탕으로 작성되었다.

아티클 순위

의견

위로

목차

• 보안 상호 운용성
• 보안 문제점 및 제한조건
• 스택 비교
• 마무리하기
• 참고자료
• 필자소개
• 의견