STSから発行されたSAMLトークンを使用して、WCFとJavaが互いに話し合おうとしています。両者が標準、WS-Security、WS-Trust、WS-Policyなどに準拠しているにもかかわらず、両者はお互いに話しているようではなく、どちらか一方が潜在的な例外を投げたり、セキュリティヘッダーを無視する。WCF WS-Trustを使用したAxis2との相互運用
私たちは、.NET側で.NET 3.5、WCF Federationバインディング、Java側でAxis2/Rampart/Rahasを使用しています。
これまで誰もこの仕事をすることができましたか？
のAxis2はWS標準準拠の面で不完全です。
私は最近（先月）、Axis2がWS- *コンプライアンステスト（特にWS-AT、WS-Coordination）に失敗したPOCフェーズを経験しました。
「Project Metro」をご覧ください。 SunとMicrosoftは、WCFとJAX-WSの相互運用性を「適切に」得ることに協力しました。
https://metro.dev.java.net/
のAxis2/Rampartのは、WS-Trustとうまく相互運用機能を完全にサポートしていますWCFでテストされています。問題がある場合は、詳細を返信してください。 –
私は、サーバー側が軸であることを仮定している、それは明確ではないのですが、それはより一般的です。
Javaで相互運用可能なWebサービスをプログラミングする場合は、JAX-WSへの切り替えを検討する必要があります。これは、axis2プログラミングモデルが少し奇妙なだけでなく、コードが不完全であることが多いからです。前に部分的に実装されていた機能を確かに見つけました。また、Microsoftのスタックでどのような相互運用性のテストが行われたのかを判断するのが難しいと感じました。
今後、JAX-WSスタックを使用して、より良い機会を得ることができます。 1つの主な理由は、Sunエンジニアが、マイクロソフトのエンジニアと会って、スタックが相互運用可能であることを確認するためにかなりの時間を費やし、同じ方法で仕様を解釈したことです。この他にも、プログラミングモデルは簡単で、注釈を使用して操作することができます。また、展開とメンテナンスがやや簡単になります。 .AARファイルをサービスするための追加のコンテナと、サービスエンドポイントからaxis2を削除する手間を無視することができます。エンドポイントは単にサーブレットとして扱うことができます。
JAX-WSで動作するようにSAMLを得る人たちのドキュメントがあります：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/[email protected]/msg10292.html
http://www2.sys-con.com/ITSG/virtualcd/WebServices/archives/0303/secrist/index.html
可能であれば、私はAxis2のJava側へ行くことをお勧めしません。明らかにGlassfishやJAX-WSの方が簡単でしょう。私は決してそれをテストしませんでした。
WCFとAxis2を連携させようとすると、私はこのような問題にも遭遇しました。 WSDLファイルで使用されている標準のバージョンを確認してください。このバージョンは、このケースでは一致しませんでした。
Axis2/RampartはWS-Trustをフルサポートしており、WCFでの相互運用性テストを実施しています。 –
クライアントとサーバーの両方でWCFを使用したRampart for WS-Trustシナリオを正常にテストしました。
BTW RampartにはWS-Federationシナリオはまだサポートされておらず、セキュリティポリシーが関連している可能性があります。 [FYI - WS - Federationは来年半ばにRampartと共に利用可能になります。
あなたは城壁の終わりにセキュリティポリシーを添付してくださいすることができ
..我々は近い外観を持つことができ、セキュリティポリシーを添付してくださいできれば... –