WCF interoperabilidad con Axis2 usando WS-Trust

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

Pregunta

Estamos tratando de conseguir WCF y Java a hablar entre sí usando tokens SAML emitidos desde un STS. A pesar del hecho de que ambas partes cumplen con las normas, WS-Security, WS-Trust, WS-Policy, etc., que no parecen hablar el uno al otro y uno o el otro va a lanzar excepciones crípticas o ignorar cabeceras de seguridad .

Estamos utilizando .NET 3.5, WCF Federación de encuadernación en el lado MS, y Axis2 / Rampart / rahas en el lado de Java.

¿Alguien ha sido capaz de hacer este trabajo?

¿Fue útil?

Solución

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

Hace poco (en el último mes) pasó por una fase de POC, donde Axis2 no mi WS * pruebas de conformidad (en concreto WS-AT, WS-Coordination).

Tener un vistazo a "Proyecto Metro". Sun y Microsoft colaboraron en conseguir WCF y JAX-WS interoperabilidad "derecho".
https://metro.dev.java.net/

Otros consejos

Me gustaría también recomiendo no ir para Axis2 en el lado de Java, si es posible. Sería más fácil con Glassfish o JAX-WS, aparentemente, althoug Nunca lo probé.

Me encontré con ese tipo de cuestiones, así cuando se trata de hacer WCF y Axis2 cooperan. Compruebe la versión del estándar utilizado en el archivo WSDL, los que no fueron coincidentes en nuestro caso.

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 que usted debe considerar el cambio a JAX-WS, no sólo porque el modelo de programación axis2 es un poco extraño, pero a menudo el código está incompleto. Ciertamente me he encontrado con características parcialmente implementado antes, también es He encontrado que es difícil determinar qué pruebas de interoperabilidad se había realizado con la pila de Microsoft.

Yo diría que tiene mucho mejores oportunidades en el futuro utilizando una pila JAX-WS. Una razón principal es Sun Ingenieros pasan bastante tiempo sentado con los ingenieros de Microsoft para asegurarse de que sus pilas eran compatibles y que habían interpretado las especificaciones de la misma manera. Además de esto el modelo de programación es más fácil y se puede conducir con anotaciones. También simplifica un poco despliegue y mantenimiento. El recipiente adicional para el servicio de archivos .AAR y el tocar el violín para eliminar axis2 desde el extremo de servicio solo puede ser ignorada:. El punto final solo puede ser tratada como un servlet

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

Si no puede alejarse de axis2 Creo que una estrategia similar necesita ser empleada. Donde le interceptar la señal y hacer la autenticación antes de que llegue a llamar al extremo de servicio.

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

http: //www.mail-archive .com / eje-usuario @ xml.apache.org / msg10292.html

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

Hemos probado con éxito Rampart para escenarios de WS-Trust con WCF tanto en el cliente y el servidor termina.

Por cierto Rampart no tiene escenarios WS-Federation todavía apoyados y su política de seguridad podrían estar relacionados con ella. . [FYI - WS-Federation estará disponible con Rampart mediados del próximo año]

Si se puede adjuntar las políticas de seguridad que podemos tener una mirada cercana ..

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top