traditional と Liberty における WS-Security の動作に関する相違点

Liberty で Web サービス・アプリケーションに加えられる可能性がある WS-Security の制約は、traditional でサービスに適用される同じ制約と動作が異なる場合があります。

WS-Security の有効化と構成

Liberty の WS-Security は、Web サービス・アプリケーションの WSDL ファイル内で WS-SecurityPolicy を使用して構成し、server.xml ファイルに wsSecurity-1.1 フィーチャーを追加して有効にします。traditional の WS-Security は、ポリシー・セットを使用して構成し、ポリシー・セットを関連付けて有効にします。 WS-Security を有効にした Liberty の Web サービス・アプリケーションを traditional にデプロイする場合は、Web サービス・セキュリティーのレベルを同じにするために、同等のポリシー・セットとバインディングを作成して関連付けてください。

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 を署名または暗号化するには、トークンを SignedSupportingTokensSignedEncryptedSupportingTokens、または EncryptedSupportingTokens として表明します。traditional では、 XPath 式を使用して SupportingToken を署名または暗号化する必要があります。

      traditional では、 EndorsingSupportingTokensSignedEndorsingSupportingTokensEndorsingEncryptedSupportingTokensSignedEndorsingEncryptedSupportingTokens を含めて、承認トークンがすべてはサポートされません。

    • セキュリティー・バインディングのアサーション

      Liberty では、SymmetricBindingAsymmetricBindingTransportBinding のアサーションをサポートします。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> エレメントを生成します。 ただし、Liberty で使用される CXF WS-Security は、<security> ヘッダーの mustUnderstand が 0 に設定されている場合に、着信の <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