WCF Interop con Axis2 utilizando WS-Trust

Question

Estamos tratando de que WCF y Java hablen entre sí utilizando tokens SAML emitidos desde un STS. A pesar del hecho de que ambas partes cumplen con los estándares, WS-Security, WS-Trust, WS-Policy, etc., no parece que se comuniquen entre sí y uno u otro lanzarán excepciones crípticas o ignorarán los encabezados de seguridad. .

Estamos utilizando .NET 3.5, unión WCF Federation en el lado MS, y Axis2/Rampart/Rahas en el lado java.

¿Alguien ha sido capaz de hacer esto?

Answer 1

Axis2 es incompleta en términos de cumplimiento de los estándares WS.

Recientemente (en el último mes) pasé por una fase POC donde Axis2 falló mis pruebas de cumplimiento WS- * (específicamente WS-AT, WS-Coordination).

Eche un vistazo a "Project Metro". Sun y Microsoft colaboraron para lograr que la interoperabilidad WCF y JAX-WS fuera "correcta".
https://metro.dev.java.net/

Answer 2

¿Está manejando el problema del doc literal contra el código rpc? (Lo siento, tengo que preguntar.)

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

Estoy asumiendo que el lado del servidor es el eje, no es clara, pero que es más común.

Si está programando servicios web interoperables, en Java debería considerar cambiar a JAX-WS, no solo porque el modelo de programación axis2 es un poco extraño, pero a menudo el código es incompleto. Ciertamente me encontré con las funciones parcialmente implementadas antes, también me resulta difícil determinar qué pruebas de interoperabilidad se han realizado con la pila de Microsoft.

Diría que tiene muchas más posibilidades en el futuro con una pila JAX-WS. Una razón importante es que Sun Engineers pasó bastante tiempo sentado con los ingenieros de Microsoft para asegurarse de que sus pilas fueran interoperables e interpretaran las especificaciones de la misma manera. Además de esto, el modelo de programación es más fácil y puede ser conducido con anotaciones. También simplifica un tanto la implementación y el mantenimiento. El contenedor adicional para el mantenimiento de los archivos .AAR y el virado para eliminar el eje2 del punto final del servicio solo se puede ignorar: el punto final solo se puede tratar como un Servlet.

Existe documentación de las personas que reciben SAML para trabajar con JAX-WS: http://www.jroller.com/gmazza/entry/using_the_opensaml_library_in

Si no puede alejarse de axis2 creo que una estrategia similar necesita ser empleada. Donde interceptaría el token y realizaría la autenticación antes de llamar al punto final del servicio.

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

Yo tampoco recomendaría ir por Axis2 en el lado de Java, si es posible. Sería más fácil con Glassfish o JAX-WS aparentemente, aunque nunca lo probé.

Me encontré con ese tipo de problemas también cuando trato de hacer que WCF y Axis2 cooperen. Compruebe la versión del estándar utilizado en el archivo WSDL, que no coincidía en nuestro caso.

Answer 5

Hemos probado satisfactoriamente Rampart para escenarios de WS-Trust con WCF tanto en el cliente como en el servidor.

BTW Rampart aún no tiene escenarios de WS-Federation admitidos y su política de seguridad podría estar relacionada con él. [FYI - WS-Federation estará disponible con Rampart a mediados del próximo año].

Si puede adjuntar las políticas de seguridad que podemos tener un vistazo de cerca ..