2012-05-14 11 views
18

jax-wsクライアントを実装する必要があります。
XMLENC(:ここ 署名と暗号化のポリシー

は、プロバイダのドキュメントは、この規格は、W3C標準から他の二つを使用して、我々は http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

でSOAPメッセージセキュリティバージョン1.0仕様を使用し、

現在、セキュリティについて言うことですhttp://www.w3.org/TR/2002/REC-xmlenc-core-20021210/
およびXMLDSIG(http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/

署名の場合、直接「 」の「参照」を使用し、X509の「URI」および「値のタイプ」を指定する「SecurityTokenReference」は必須です。 暗号化については、私たちも推奨しますが、 の順番で、keyIdentifier、X509IssuerSerial、または keyNameへの参照をサポートしています。

暗号化され署名されたブロックは、 "body"タグでなければなりません。

シグネチャには「rsa-sha1」、暗号化キーには では「rsa-1_5」、本文を暗号化するには「tripledes-cbc」を使用することをお勧めします。

私は(netbeansから生成された)次のポリシーを考え出しました。しかし、それは私には見えません。 Webサービスにまだ到達できませんが、仕様バージョンが一致しているかどうかはわかりません。私は主題についてたくさん読むが、私はまだやや混乱している。このポリシーは大丈夫ですか?

<wsp1:Policy wsu:Id="ListeOperationsPeriodeSoapBindingSoapPolicy"> 
    <wsp1:ExactlyOne> 
     <wsp1:All> 
      <sp:TransportBinding> 
       <wsp1:Policy> 
        <sp:TransportToken> 
         <wsp1:Policy> 
          <sp:HttpsToken RequireClientCertificate="false"/> 
         </wsp1:Policy> 
        </sp:TransportToken> 
        <sp:Layout> 
         <wsp1:Policy> 
          <sp:Lax/> 
         </wsp1:Policy> 
        </sp:Layout> 
        <sp:AlgorithmSuite> 
         <wsp1:Policy> 
          <sp:TripleDesRsa15/> 
         </wsp1:Policy> 
        </sp:AlgorithmSuite> 
       </wsp1:Policy> 
      </sp:TransportBinding> 
      <sp:Wss10/> 
      <sp:EndorsingSupportingTokens> 
       <wsp1:Policy> 
        <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient"> 
         <wsp1:Policy> 
          <sp:WssX509V3Token10/> 
         </wsp1:Policy> 
        </sp:X509Token> 
       </wsp1:Policy> 
      </sp:EndorsingSupportingTokens> 

     </wsp1:All> 
    </wsp1:ExactlyOne> 
</wsp1:Policy> 
<wsp:Policy wsu:Id="ListeOperationsPeriodeSoapBindingSoap_perform_Input_Policy"> 
    <wsp:ExactlyOne> 
     <wsp:All> 
      <sp1:SignedEncryptedSupportingTokens> 
       <wsp:Policy> 
        <sp1:X509Token sp1:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"> 
         <wsp:Policy> 
          <sp1:WssX509V3Token10/> 
         </wsp:Policy> 
        </sp1:X509Token> 
       </wsp:Policy> 
      </sp1:SignedEncryptedSupportingTokens> 
     </wsp:All> 
    </wsp:ExactlyOne> 

</wsp:Policy> 

EDIT: が、私はそれがまだWSIT-と予想メッセージを送信するために得ることができませんでした。たとえば、Netbeansウィザードを使用して、アドレス指定を使わずに暗号化されたヘッダーを取得できませんでした。それは可能であると思われますか?

私は古い軸1クラスとwss4jで何かをハックしましたが、それは動作しますが、それは醜いです。

+0

大きな賞金は助けてくれますか? – ymajoros

+0

wsit-yetで期待したメッセージを送ることができませんでした。たとえば、Netbeansウィザードを使用して、アドレス指定を使わずに暗号化されたヘッダーを取得できませんでした。それは可能であると思われますか?私は古い軸1クラスとwss4jで何かをハックしましたが、それは動作しますが、それは醜いです。 – ymajoros

+0

これは、コードレビューサイトに属するコードレビューの問題です。 – user1378730

答えて

1

WSITの代わりにCXFを試したいのですか? http://cxf.apache.org/docs/ws-security.html

+0

できます。私は醜いハックで私の問題を解決しました。プロバイダは、セキュリティの制約を受けて、おそらく来年程度の間、まともなwsdlを作ると言います。彼らが望むとき、私はwsitを使用し、それはうまくいくはずです。その間、私の醜いハックが働きます。 – ymajoros

+0

あなたの醜いハックにCXFを使用しましたか? – adosaiguas

+0

いいえ、私はmetro/wss4jで動作する構成を持っていたので、wss4jとmetro 1のいくつかのクラスをmetroで動作させるように変更しました。私は基本的にメトロクラスをコピーして変更したので、メトロには依存しません。私はまだメトロが正しい選択だと信じています。私はwss4jを深く見なければならなかったので、地獄のように汚れていることを保証します。 – ymajoros

1

あなたは本当に混乱しているようです。一般的には、単一のポリシーが必要です。あなたのケースでは、トランスポートバインディング(https)を定義するポリシーが1つあり、もう1つはそうでないため、セキュリティで保護されていないWebサービスコールを受け入れる危険性があります。

また、トランスポートバインディングがあるため、トランスポートプロトコル(https)で全身が暗号化されます。身体の暗号化を明示的に指定する必要はありません。実際、このバインディングは、httpヘッダー以外のすべてを暗号化します。

トランスポートバインディングは、実際に安全なWebサービスを取得する最も簡単な方法です。完全な制御が必要な場合は、必要に応じて独自の対称または非対称のバインドを作成する必要があります。非対称型はサーバー証明書のみを必要とする(匿名クライアントを受け入れる)一方で、非対称型は両側で証明書を必要とするため、より複雑です。非対称および対称バインディングには注意が必要です。柔軟性が高く、特定の攻撃に対して脆弱であっても、あらゆるポリシーを設計できるように設計されています。

トランスポートバインディングを使用しない場合は、本文を暗号化する必要があることを指定する必要があります。スペックで述べたように:

sp:EncryptedParts/sp:Body 

またはXMLに変換:

<sp:SignedParts> 
    <sp:Body/> 
</sp:SignedParts> 

が署名を指定するためのより多くのオプションがあります:あなたは体が署名する場合は、

<sp:EncryptedParts> 
    <sp:Body/> 
</sp:EncryptedParts> 

同様に/暗号化の順序、署名を暗号化するかどうかなどを指定します。

名前が示すとおり、policie sp:EndorsingSupportingTokenなどのトークンは、サポートトークンに適用されます。私がよく知っているタイプは、Webサービス要求の中に含めることができるユーザー名トークンです。

WS-SecurityPolicy specificationは、ポリシーを理解するために私が読んだもっとも有用なドキュメントです。あなたはこれを徹底的に読むために時間を取るべきです。それは物事を非常によく詳述し、有用な例を含んでいます。より新しいバージョンではいくつかの側面がよりよく文書化されるので、異なるバージョンのドキュメントを読むことは良いことです。注:私はv1.3をリンクしました。

Webサービスのクライアントとサーバーをセットアップし、簡単なテストを作成します。特にあなたがウェブサービスを初めて利用している場合。

ポリシーを迅速に策定するのに役立つツールの1つはSoapUIです。それは私が必要なものを正確にサポートしませんでしたが、それは私がいくつかのことを学ぶのを助けました。それは素晴らしいUIを持っており、使用することはあまり難しくありません。

いくつかの例を入手したり構築したりしてから、仕様の助けを借りて分解してください。

私はかなり複雑なポリシーを見つけました。多くの概念を吸収する準備をしてください!

+0

まあ、私は選択肢がありませんでした。私はクライアントであり、他のクライアントが使用しているサーバーについては何も言及していません。私はセキュリティ上の制約がないwsdlを持っていました。これは交渉可能ではありませんでした。 – ymajoros

+0

パートナーはあまり協力していません。おそらく彼らはあなたが彼らのサービスを呼び出すことに興味を持っているわけではないでしょうか?彼らがクライアント認証を行う場合、あなたは適切なクライアント証明書なしでサービスを呼び出すことはできません。ユーザー名+パスワードトークンが必要な場合は、サービスを呼び出すことはできません。多分、彼らはhttpsで匿名のクライアントを受け入れるだろうか?それを試してみてください。 httpsセキュリティを使用してシンプルなWebサービスをコーディングします(つまり、単一のhello world関数)。その後、対応するクライアントをコーディングします。それがうまくいったら、あなたの指を渡り、「本物の」サービスで試してみてください。 –

+0

「私のパートナー」は本当に私のクライアントのパートナーであり、とにかく独占権を持っているので、私たちは選択肢がなく、いつでも変わらない状態になっているので、ウェブサービスを呼び出す必要がありますすぐに。彼らは世界を支配し、彼らが何をするか(技術ではなくビジネス)に驚くでしょう。とにかく、私は数ヶ月以来、生産上で動作する上記の醜いハックを持っている。 – ymajoros

関連する問題