Traditional과 Liberty 간 WS-Security 동작 차이

Liberty의 웹 서비스 애플리케이션에 추가할 수 있는 WS-Security 제한조건은 Traditional의 서비스에 적용된 동일한 제한조건과 다르게 동작할 수 있습니다.

WS-Security 사용 및 구성

Liberty의 WS-Security는 웹 서비스 애플리케이션의 WSDL 파일 내에서 WS-SecurityPolicy를 사용하여 구성되며, server.xml 파일의 wsSecurity-1.1 기능을 추가함으로써 사용됩니다. Traditional의 WS-Security는 policyset를 사용하여 구성되며 policyset를 첨부하여 사용으로 설정됩니다. WS-Security 사용 Liberty 웹 서비스 애플리케이션을 Traditional에 배치하는 경우에는 동등한 policyset 및 바인딩을 작성한 후 첨부하여 동일한 레벨의 웹 서비스 보안을 확보해야 합니다.

WS-Security 정책

  • 네임스페이스
    • Liberty CXF WS-Security는 다음 WS-Security 정책 네임스페이스를 지원합니다.
      http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702
      http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802
    • 다음 네임스페이스 역시 제한사항과 함께 지원됩니다.
      http://schemas.xmlsoap.org/ws/2005/07/securitypolicy
    • Traditional의 WS-Security는 다음과 같은 WS-Security 정책 네임스페이스를 지원합니다.
      http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512
  • 어설션
    Liberty는 WS-Security 정책 1.2에서 Traditional보다 많은 어설션을 지원합니다. Traditional WS-Security에서 일부 정책 어설션은 XPath 또는 바인딩을 통해 구현됩니다. 다음 목록은 중요한 차이점을 보여줍니다.
    • 지원 토큰

      Liberty에서 UsernameToken 등의 SupportingToken을 서명하거나 암호화하려면, 토큰을 SignedSupportingTokens, SignedEncryptedSupportingTokens 또는 EncryptedSupportingTokens로서 어설션하십시오. Traditional에서는 XPath 표현식을 사용하여 SupportingToken에 서명하거나 이를 암호화해야 합니다.

      EndorsingSupportingTokens, SignedEndorsingSupportingTokens, EndorsingEncryptedSupportingTokensSignedEndorsingEncryptedSupportingTokens를 포함하여 모든 Endorsing 토큰은 Traditional에서 지원되지 않습니다.

    • 보안 바인딩 어설션

      Liberty는 SymmetricBinding, AsymmetricBindingTransportBinding 어설션을 지원합니다. Traditional 서버는 TransportBinding 어설션을 지원하지 않습니다.

    • IncludeToken 어설션

      IncludeToken 어설션은 Liberty에서는 강제 실행되지만 Traditional의 WS-Security 런타임 환경에서는 무시됩니다.

    • UsernameToken 어설션

      Liberty는 UsernameToken 어설션의 키 파생과 PasswordDigest를 지원합니다. WebSphere Application Server Traditional에서는 UsernameToken에서 PasswordText만 지원합니다.

보안 헤더의 인식되지 않는 요소

  • 보안 헤더의 인식되지 않는 요소는 Traditional에서 거부되지만 Liberty에서는 허용됩니다.

암호화된 헤더

  • WS-Security 1.1 스펙은 SOAP 헤더 블록 암호화에 대해 <wsse11:EncryptedHeader> 요소 사용을 권장합니다.
    • Liberty에서 사용되는 CXF WS-Security는 EncryptedHeader 요소를 생성하지 않습니다. 그 대신에, CXF WS-Security는 <xenc:EncryptedData> 요소를 생성합니다. 그러나 <security> 헤더의 mustUnderstand가 0으로 설정된 경우, Liberty에서 사용되는 CXF WS-Security는 수신 <wsse11:EncryptedHeader> 요소를 처리하고 이용할 수 있습니다.
    • WebSphere® Application Server Traditional은 항상 <security> 헤더에서 mustUnderstand를 1로 설정합니다. Liberty가 EncryptedHeader 요소를 성공적으로 처리할 수 있도록 하려면, 아웃바운드 바인딩 구성에서 다음 특성을 설정하여 mustUnderstand를 0으로 명시적으로 설정해야 합니다.
      <properties name="com.ibm.wsspi.wssecurity.config.request.setMustUnderstand" value="false"/>

중간 비신뢰 인증서

  • 인증서 경로 유효성 검증기가 인바운드 인증서에서 신뢰 저장소의 신뢰되는 인증서로 빌드할 수 있도록 중간 비신뢰 인증서를 지정할 수 있는 방법은 없습니다. 인바운드 인증서나 즉시 발행자는 신뢰할 인증서에 대해 신뢰 저장소에 있어야 합니다.

알려진 문제

  • Liberty CXF WS-Security에는 알려진 문제가 일부 있습니다. 일부 문제는 해결되었습니다. 알려진 문제와 해결책을 찾으려면, WS-Security 알려진 문제 및 해결책을 참조하십시오.

테스트되거나 지원되지 않은 기능

  • Liberty WS-Security에는 CXF 프로젝트의 모든 WS-Security 런타임 환경 코드가 포함됩니다. 그러나 CXF WS-Security의 모든 함수 및 기능이 테스트되거나 확인된 것은 아닙니다. 확인되지 않은 스펙의 목록을 보려면 테스트되지 않은 WS-Security 스펙을 참조하십시오.

주제의 유형을 표시하는 아이콘 개념 주제



시간소인 아이콘 마지막 업데이트 날짜: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwlp_wssec_cxf_diff
파일 이름: cwlp_wssec_cxf_diff.html