WCF Interop avec Axis2 en utilisant WS-Trust

Question

Nous essayons de faire dialoguer WCF et Java en utilisant des jetons SAML émis par un STS. Malgré le fait que les deux parties sont conformes aux normes, WS-Security, WS-Trust, WS-Policy, etc., elles ne semblent pas se parler et l'une ou l'autre va lancer des exceptions cryptiques ou ignorer les en-têtes de sécurité .

Nous utilisons .NET 3.5, liaison de la fédération WCF du côté MS, et Axis2/Rampart/Rahas du côté java.

Est-ce que quelqu'un a déjà été capable de faire ce travail?

Answer 1

Axis2 est incomplète en termes de conformité aux normes WS.

J'ai récemment (au cours du dernier mois) passé une phase POC où Axis2 a échoué à mes tests de conformité WS- * (spécifiquement WS-AT, WS-Coordination).

Jetez un oeil à "Projet Metro". Sun et Microsoft ont collaboré pour obtenir l'interopérabilité entre WCF et JAX-WS.
https://metro.dev.java.net/

Answer 2

Êtes-vous en train de gérer le problème de doc littéral par rapport au codage rpc? (Désolé, doivent demander.)

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

Je suppose que le côté serveur est l'axe, on ne sait pas, mais qui est plus commun.

Si vous programmez des services Web interopérables en Java, vous devriez envisager de passer à JAX-WS, non seulement parce que le modèle de programmation axis2 est un peu bizarre, mais souvent le code est incomplet. J'ai certainement rencontré des fonctionnalités partiellement mises en œuvre auparavant, aussi il m'était difficile de déterminer quel test d'interopérabilité avait été effectué avec la pile Microsoft.

Je dirais que vous avez de meilleures chances dans le futur en utilisant une pile JAX-WS. L'une des principales raisons est que les ingénieurs de Sun passent beaucoup de temps assis avec des ingénieurs de Microsoft pour s'assurer que leurs piles sont interopérables et qu'ils ont interprété les spécifications de la même manière. En outre, le modèle de programmation est plus facile et peut être piloté par des annotations. Cela simplifie également un peu le déploiement et la maintenance. Le conteneur supplémentaire pour l'entretien des fichiers .AAR et le fiddling pour retirer axis2 du point de terminaison du service peuvent simplement être ignorés: le point final peut simplement être traité comme une servlet.

Il y a la documentation des gens qui se SAML à travailler avec JAX-WS: http://www.jroller.com/gmazza/entry/using_the_opensaml_library_in

Si vous ne pouvez pas déplacer loin de axis2 je pense une stratégie similaire doit être employée. Où vous intercepteriez le jeton et effectueriez l'authentification avant d'appeler le point de terminaison du service.

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

Je ne vous recommande pas non plus d'utiliser Axis2 du côté Java, si vous le pouvez. Serait plus facile avec Glassfish ou JAX-WS apparemment, bien que je ne l'ai jamais testé.

J'ai également rencontré ce genre de problème lorsque j'essayais de faire coopérer WCF et Axis2. Vérifiez la version de la norme utilisée dans le fichier WSDL, celles-ci ne correspondaient pas dans notre cas.

Answer 5

Nous avons testé avec succès les scénarios Rampart pour WS-Trust avec WCF aux extrémités client et serveur. BTW Rampart n'a pas encore de scénarios WS-Federation supportés et votre politique de sécurité pourrait y être liée. [FYI - WS-Federation sera disponible avec Rampart au milieu de l'année prochaine].

Si vous s'il vous plaît joindre les politiques de sécurité, nous pouvons voir de près ..