STSから発行されたSAMLトークンを使用して、WCFとJavaが相互に通信できるようにしようとしています。双方が標準、WS-Security、WS-Trust、WS-Policyなどに準拠しているという事実にもかかわらず、それらは互いに通信していないようであり、どちらか一方が不可解な例外をスローするか、セキュリティヘッダーを無視します。
.NET 3.5、MS側でWCFフェデレーションバインディング、Java側でAxis2 / Rampart/Rahasを使用しています。
誰かがこの仕事をすることができたことがありますか？
Axis2 は、WS 標準への準拠という点では不完全です。
私は最近 (先月)、Axis2 が WS-* 準拠テスト (具体的には WS-AT、WS-Coordination) に失敗した POC フェーズを経験しました。
「プロジェクトメトロ」をご覧ください。Sun と Microsoft は、WCF と JAX-WS の相互運用を「正しく」実現するために協力しました。
https://metro.dev.java.net/
可能であれば、Java 側で Axis2 を使用することもお勧めしません。GlassfishまたはJAX-WSを使用すると明らかに簡単になりますが、テストしたことはありません。
WCF と Axis2 を連携させようとしたときにも、この種の問題に遭遇しました。WSDL ファイルで使用されている標準のバージョンを確認してください。今回のケースでは一致していませんでした。
doc リテラルと rpc エンコードの問題を処理していますか? （すみません、質問させてください。）
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
サーバー側が軸であると想定しています。明確ではありませんが、それがより一般的です。
Java で相互運用可能な Web サービスをプログラミングしている場合は、JAX-WS への切り替えを検討する必要があります。これは、axis2 プログラミング モデルが少し奇妙であるだけでなく、多くの場合、コードが不完全であるためです。以前に部分的に実装された機能に出くわしたことは確かです。また、Microsoft スタックで実行された相互運用性のテストを判断するのが難しいこともわかりました。
将来、JAX-WS スタックを使用する可能性がはるかに高くなると思います。主な理由の 1 つは、Sun のエンジニアが Microsoft のエンジニアとかなりの時間を費やして、スタックが相互運用可能であり、仕様を同じように解釈していることを確認したことです。これに加えて、プログラミング モデルはより簡単で、注釈を使用して駆動できます。また、展開とメンテナンスが多少簡素化されます。.AAR ファイルを処理するための追加のコンテナーと、サービス エンドポイントから axis2 を削除するための手間は無視できます。エンドポイントは単にサーブレットとして扱うことができます。
SAML を JAX-WS で動作させるためのドキュメントがあります: http://www.jroller.com/gmazza/entry/using_the_opensaml_library_in
axis2 から離れられない場合は、同様の戦略を採用する必要があると思います。サービスエンドポイントを呼び出す前に、トークンをインターセプトして認証を行う場所。
参照: http://www.omg.org/news/meetings/workshops/Web_Services_USA_Manual/02-3_K_Smith.pdf
http://www.mail-archive.com/axis-user@xml.apache.org/msg10292.html
http://www2.sys-con.com/ITSG/virtualcd/WebServices/archives/0303/secrist/index.html
クライアント側とサーバー側の両方で、WCF を使用した WS-Trust シナリオの Rampart のテストに成功しました。
ところで、Rampart にはまだ WS-Federation シナリオがサポートされておらず、セキュリティ ポリシーがそれに関連している可能性があります。[参考 - WS-Federation は来年半ばに Rampart で利用可能になります]。
セキュリティ ポリシーを添付していただければ、詳細を確認できます..