WCF Interop mit Axis2 WS-Trust mit

StackOverflow https://stackoverflow.com/questions/785652

Frage

Wir versuchen, WCF zu bekommen und Java miteinander zu reden mit SAML-Token von einem STS ausgegeben. Trotz der Tatsache, dass beide Seiten mit den Standards kompatibel sind, WS-Security, WS-Trust, WS-Policy, usw., scheinen sie nicht miteinander und das eine oder andere zu reden kryptischen Ausnahmen oder Sicherheitsüberschriften werfen ignorieren .

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

Hat jemand schon einmal in der Lage, diese Arbeit zu machen?

War es hilfreich?

Lösung

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

Ich habe vor kurzem (im letzten Monat) ging durch eine Phase, in der POC Axis2 meine WS- fehlgeschlagen * Compliance-Tests (speziell WS-AT, WS-Coordination).

Haben Sie einen Blick auf „Projekt Metro“. Sun und Microsoft zusammengearbeitet, auf immer WCF und JAX-WS-Interop "rechts".
https://metro.dev.java.net/

Andere Tipps

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

Ich lief in diese Art von Fragen sowie bei der WCF und Axis2 kooperieren zu machen versuchen. Überprüfen Sie die Version des Standards in der WSDL-Datei verwendet wird, passend zu denen, wurden nicht in unserem Fall.

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

Wenn Sie interoperablen Webservices programmieren Sie in Java Sie JAX-WS Umschalten in Betracht ziehen sollten, nicht nur, weil das axis2 programing Modell ist ein wenig bizarr, aber oft der Code ist unvollständig. Ich habe über sicherlich kommt Features vor teilweise umgesetzt, auch es ist, fand ich es schwierig zu bestimmen, welche Tests für die Interoperabilität mit dem Microsoft-Stack durchgeführt worden war.

Ich würde sagen, Sie viel bessere Chancen in der Zukunft haben einen JAX-WS-Stack verwenden. Ein wichtiger Grund ist Sun Ingenieure verbringen einige Zeit mit Microsoft Ingenieure sitzen, um sicherzustellen, ihre Stacks waren kompatibel und sie hatten die Spezifikationen in der gleichen Art und Weise interpretiert. Außerdem ist das Programmiermodell einfacher und kann mit Anmerkungen angetrieben werden. Es vereinfacht auch etwas Bereitstellung und Wartung. Der zusätzliche Behälter für die Wartung .AAR Dateien und das Hantieren axis2 vom Service-Endpunkt zu entfernen, 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 würden Sie das Token abfangen und die Authentifizierung tun, bevor sie den Service-Endpunkt aufrufen wird.

Siehe auch: 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

Wir haben erfolgreich Rampart für WS-Trust-Szenarien mit WCF sowohl auf dem Client und dem Server beendet getestet.

BTW Rampart nicht WS-Federation Szenarien noch unterstützt haben und die Sicherheitspolitik mit sich bringen könnte. . [FYI - WS-Federation wird mit Rampart Mitte nächstes Jahr verfügbar sein]

Wenn Sie bitte die Sicherheitsrichtlinien anhängen können wir einen genauen Blick haben ..

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top