WCF-Interop mit Axis2 unter Verwendung von WS-Trust

Question

Wir versuchen, WCF und Java mit SAML-Tokens zu kommunizieren, die von einem STS ausgegeben werden. Trotz der Tatsache, dass beide Seiten mit den Standards WS-Security, WS-Trust, WS-Policy usw. übereinstimmen, scheinen sie nicht miteinander zu reden und der eine oder andere wird kryptische Exceptions werfen oder Security-Header ignorieren .

Wir verwenden .NET 3.5, WCF Federation-Bindung auf der MS-Seite und Axis2/Rampart/Rahas auf der Java-Seite.

Hat jemals jemand diese Arbeit machen können?

Answer 1

Axis2 ist unvollständig in Bezug auf die WS Einhaltung von Standards.

Ich habe vor kurzem (im letzten Monat) eine POC-Phase durchlaufen, in der Axis2 meine WS- * Konformitätstests (speziell WS-AT, WS-Coordination) nicht bestanden hat.

Werfen Sie einen Blick auf "Projekt Metro". Sun und Microsoft arbeiteten zusammen, um WCF und JAX-WS interop "richtig" zu machen.

Answer 2

Handelt es sich um das dokumentliterale vs. rpc-codierte Problem? (Sorry, müssen fragen.)

http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/

http://www.developerfusion.com/article/4694/web-services-interoperability-between-j2ee-and-net-part-1/3/

http://msdn.microsoft.com/en-us/library/ms996466.aspx

Answer 3

Ich gehe davon aus, dass die Server-Seite Achse ist, es ist nicht klar, aber das ist häufiger.

Wenn Sie in Java interoperable Webservices programmieren, sollten Sie den Wechsel zu JAX-WS in Betracht ziehen, nicht nur, weil das Programmiermodell axis2 etwas bizarr ist, sondern der Code oft unvollständig ist. Ich bin sicherlich auf Funktionen gestoßen, die zum Teil bereits implementiert waren, und es fiel mir schwer zu bestimmen, welche Tests für die Interoperabilität mit dem Microsoft-Stack durchgeführt wurden.

Ich würde sagen, Sie haben viel bessere Chancen in der Zukunft mit einem JAX-WS-Stack. Ein Hauptgrund dafür ist, dass Sun Engineers viel Zeit damit verbringen, mit Microsoft-Ingenieuren zusammenzuarbeiten, um sicherzustellen, dass ihre Stacks interoperabel sind und sie die Spezifikationen auf die gleiche Weise interpretiert haben. Außerdem ist das Programmiermodell einfacher und kann mit Anmerkungen gefahren werden. Es vereinfacht auch die Bereitstellung und Wartung. Der zusätzliche Container zum Bedienen von .AAR-Dateien und das Fiedeln zum Entfernen von axis2 vom Service-Endpunkt kann einfach ignoriert werden: Der Endpunkt kann nur als Servlet behandelt werden.

Es ist die Dokumentation von Menschen SAML immer mit JAX-WS zu arbeiten: http://www.jroller.com/gmazza/entry/using_the_opensaml_library_in

Wenn Sie nicht weg von axis2 bewegen kann denke ich, eine ähnliche Strategie verwendet werden muss. Wo Sie das Token abfangen und die Authentifizierung ausführen würden, bevor es den Service-Endpunkt aufrufen kann.

See: 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

Answer 4

Ich würde auch nicht für Axis2 auf der Java-Seite empfehlen, wenn Sie können. Wäre leichter mit Glassfish oder JAX-WS, obwohl ich es nie getestet habe.

Ich stieß auch auf diese Art von Problemen beim Versuch, WCF und Axis2 zusammenzuarbeiten. Überprüfen Sie die Version des in der WSDL-Datei verwendeten Standards, die in unserem Fall nicht übereinstimmte.

Answer 5

Wir haben Rampart für WS-Trust-Szenarien mit WCF sowohl am Client- als auch am Serverende erfolgreich getestet.

BTW Rampart unterstützt noch keine WS-Federation-Szenarien und Ihre Sicherheitsrichtlinie könnte damit in Zusammenhang stehen. [FYI - WS-Federation wird Mitte nächsten Jahres bei Rampart erhältlich sein].

Wenn Sie bitte die Sicherheitsrichtlinien legen wir einen genauen Blick haben ..