WCF Interop with Axis2 using WS-Trust

问题:

We are trying to get WCF and Java talking to each other using SAML tokens issued from an STS. Despite the fact that both sides are compliant with the standards, WS-Security, WS-Trust, WS-Policy, etc., they don't seem to talk to each other and one or the other will throw cryptic exceptions or ignore security headers.

We are using .NET 3.5, WCF Federation binding on the MS side, and Axis2/Rampart/Rahas on the java side.

Has anyone ever been able to make this work?

回答1:

Axis2 is incomplete in terms of WS standards compliance.

I recently (in the last month) went through a POC phase where Axis2 failed my WS-* compliance tests (specifically WS-AT, WS-Coordination).

Have a look at "Project Metro". Sun and Microsoft collaborated on getting WCF and JAX-WS interop "right".
https://metro.dev.java.net/

回答2:

I would also not recommand going for Axis2 on the Java side, if you can. Would be easier with Glassfish or JAX-WS apparently, althoug I never tested it.

I ran into those kind of issues as well when trying to make WCF and Axis2 cooperate. Check the version of the standard used in the WSDL file, those were not matching in our case.

回答3:

Are you handling the doc literal vs. rpc-encoded issue? (Sorry, have to ask.)

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

回答4:

I'm assuming that the server side is axis, it's not clear but that is more common.

If you are programming interoperable webservices you in Java you should consider switching to JAX-WS, not only because the axis2 programing model is a little bizarre, but often the code is incomplete. I've certainly come across features partially implemented before, also it's I found it difficult to determine what testing for interoperability had been performed with the Microsoft stack.

I would say you have much better chances in the future using a JAX-WS stack. One major reason is Sun Engineers spend quite some time sitting with Microsoft engineers to make sure their stacks were interoperable and they'd interpreted the specs in the same way. Besides this the programming model is easier and can be driven with annotations. It also somewhat simplifies deployment and maintenance. The additional container for servicing .AAR files and the fiddling to remove axis2 from the service endpoint can just be ignored: the endpoint can just be treated as a Servlet.

There is documentation of people getting SAML to work with JAX-WS: http://www.jroller.com/gmazza/entry/using_the_opensaml_library_in

If you cannot move away from axis2 I think a similar strategy needs to be employed. Where you would intercept the token and do the authentication before it gets to call the service endpoint.

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

http://www.mail-archive.com/[e-mail]/msg10292.html

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

回答5:

We have successfully tested Rampart for WS-Trust scenarios with WCF both at the client and server ends.

BTW Rampart doesn't have WS-Federation scenarios supported yet and your security policy could be related to it. [FYI - WS-Federation will be available with Rampart mid next year].

If you can please attach the security policies we can have a close look..