Question

Nous essayons d'obtenir de la WCF et la Java de parler les uns aux autres à l'aide de jetons SAML émise à partir d'une STS.Malgré le fait que les deux côtés sont conformes aux normes, WS-Security, WS-Trust, WS-policy, etc., ils ne semblent pas à parler les uns aux autres et l'un ou l'autre va jeter cryptique exceptions ou d'ignorer la sécurité des en-têtes.

Nous utilisons .NET 3.5, WCF Fédération de liaison sur le MME côté, et Axis2/Rempart/Rahas sur le java côté.

Quelqu'un a jamais été en mesure de faire ce travail?

Était-ce utile?

La solution

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

Je récemment (au cours du dernier mois) passé par une phase de POC où Axis2 échoué mon WS- * tests de conformité (en particulier WS-AT, WS-Coordination).

Jetez un oeil à "Metro Project". Sun et Microsoft ont collaboré sur l'obtention WCF et Interop "droit" JAX-WS.
https://metro.dev.java.net/

Autres conseils

Je ne vais pas aussi recommand pour Axis2 du côté Java, si vous le pouvez. Ce serait plus facile avec Glassfish ou JAX-WS apparemment, je ne althoug testé.

Je suis tombé sur ce genre de questions et en essayant de faire coopérer WCF et Axis2. Vérifiez la version de la norme utilisée dans le fichier WSDL, ce ne sont pas assortis dans notre cas.

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

Si vous programmez webservices interopérables vous 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. Je viens certainement ai fonctionnalités à travers partiellement mises en application avant, aussi est je l'ai trouvé difficile de déterminer ce que les tests d'interopérabilité ont été effectuées avec la pile Microsoft.

Je dirais que vous avez beaucoup plus de chances dans l'avenir à l'aide d'une pile JAX-WS. Une des principales raisons est Sun ingénieurs passent un certain temps assis avec les ingénieurs de Microsoft pour que leurs piles étaient interopérables et ils avaient interprété les spécifications de la même manière. En outre le modèle de programmation est plus facile et peut être commandé avec des annotations. Il simplifie également le déploiement et la maintenance un peu. Le conteneur supplémentaire pour la gestion des fichiers .AAR et le tripotage pour enlever axis2 du point de terminaison de service peut juste être ignoré. Le point final peut simplement être traité comme un Servlet

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

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

Voir: http://www.omg.org /news/meetings/workshops/Web_Services_USA_Manual/02-3_K_Smith.pdf

http: //www.mail-archive .com / axe utilisateur @ xml.apache.org / msg10292.html

http: //www2.sys -con.com/ITSG/virtualcd/WebServices/archives/0303/secrist/index.html

Nous avons testé avec succès Rampart pour les scénarios WS-Trust avec WCF tant au niveau du client et se termine serveur.

BTW Rempart n'a pas de scénarios WS-Federation soutenu encore et votre politique de sécurité pourraient être liées à elle. . [Pour votre information - WS-Federation sera disponible avec Rempart milieu de l'année prochaine]

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

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top