Well, I just realized that "must understand" error was a configuration error I made updating CXF to 2.3.2. Sorry for that. By the way, I have to adapt your example to my use case since we adopted a code-first approach for our ws. But I think that the new cxf 2.3.2 feature of @Policy annotation can be the key to solve our problem: it should be just a matter of putting the right ws-policy elements into the wsdl generated by CXF, shouldn't it?
Thanks again for the hint and for the example: I really appreciated. Matteo On Jan 28, 2011, at 9:33 PM, Dennis Sosnoski <[email protected]> wrote: > The CXF configuration needs to include the security code, which on the > server is set up in the web.xml file using <context-param> parameters. > Though I don't see anything in that for the addressing support. > > Why don't you start with the example code provided in the article (which > should work with the current CXF code), then start making changes? > > - Dennis > > > On 01/29/2011 03:26 AM, matteo rulli wrote: >> Thanks for your response! I tried what you suggested but now I’m getting the >> following error: >> >> org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: >> [{http://www.w3.org/2005/08/addressing}Action, >> {http://www.w3.org/2005/08/addressing}To, >> {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1 >> .0.xsd}Security] are not understood. >> >> >> >> Maybe CXF needs some external library to handle these headers? What puzzle >> me a bit is that the security header is not understood… Should not this be >> the job of wss4j??? >> >> >> >> Thanks, >> >> matteo >> >> Da: Dennis Sosnoski [mailto:[email protected]] >> Inviato: venerdì 28 gennaio 2011 09:07 >> A: [email protected] >> Oggetto: Re: CXF and WCF interoperability >> >> >> >> Hi Matteo, >> >> I'd think you'd be better off using WS-SecurityPolicy configurations for >> your security handling. If the security policy configurations are >> reasonably simple (which sounds like your case) and clean they should >> work across a range of stacks. >> >> You can see my article discussing CXF WS-SecurityPolicy basics for a >> starting point: http://www.ibm.com/developerworks/java/library/j-jws13.html >> >> - Dennis >> >> Dennis M. Sosnoski >> Java SOA and Web Services Consulting <http://www.sosnoski.com/consult.html> >> Axis2/CXF/Metro SOA and Web Services Training >> <http://www.sosnoski.com/training.html> >> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html> >> >> >> On 01/28/2011 08:53 PM, matteo rulli wrote: >> >>> Dear all, >>> >>> we have been working with CXF for a year and we are completely satisfied >>> with that. In the last week we had the idea to interact with a Microsoft >>> >> WCF >> >>> client (.net 4.0). We managed to interact quite well generating the WCF >>> proxy from the wsdl published by CXF. Then we threw ws-security in to that >>> and the maelstrom began. >>> >>> >>> >>> We protect envelopes at message level with X.509 certs and we are using >>> mutual auth. with msg body signature and encryption. Server-side (CXF) we >>> are using WSS4J as security provider and we have the following >>> configuration: >>> >>> >>> >>> outProps.put("action","UsernameToken Signature Encrypt"); >>> >>> outProps.put("passwordType","PasswordText"); >>> >>> outProps.put("user",user); >>> >>> outProps.put("signatureUser","serverx509v1"); >>> >>> >>> >>> >> outProps.put("passwordCallbackClass","plat1.ws.security.handlers.UTPasswordC >> >>> allback"); >>> >>> outProps.put("encryptionUser","clientx509v1"); >>> >>> outProps.put("encryptionPropFile","Server_SignVerf.properties"); >>> >>> outProps.put("encryptionKeyIdentifier", "IssuerSerial"); >>> >>> >>> >>> >> outProps.put("encryptionParts","{Content}{http://schemas.xmlsoap.org/soap/en >> >>> velope/}Body"); >>> >>> outProps.put("signaturePropFile","Server_Decrypt.properties"); >>> >>> outProps.put("signatureKeyIdentifier", "DirectReference"); >>> >>> >>> >>> >> outProps.put("signatureParts","{Element}{http://schemas.xmlsoap.org/soap/env >> >>> elope/}Body"); >>> >>> >>> >>> where >>> >>> >>> >> org.apache.ws.security.crypto.provider=org.apache.ws.security.components.cry >> >>> pto.Merlin >>> >>> org.apache.ws.security.crypto.merlin.keystore.type=jks >>> >>> >>> >>> The point is that we are not able to implement a WCF client which is able >>> >> to >> >>> interact with our server: could anybody suggest where we could find a >>> working example/how-to? I found this claim about CXF: >>> >>> "The GOOD news is that CXF 2.2 now passes the Microsoft >>> Interop PlugFest tests for WS-Security 1.0 and 1.1, WS-SecureConversation, >>> and the client side portion of WS-Trust 1.0 and parts of WS-Trust 1.3. >>> That's a >>> >>> huge step forward in interopability with WCF." >>> >>> So I think someone should have produced a test-bench for these >>> interoperability tests: does anybody know if this test-bench is publicly >>> available? >>> >>> >>> >>> Thank you very much. >>> >>> >>> >>> Matteo Rulli >>> >>> >>> >>> >>> >>> >> _____ >> >> Nessun virus nel messaggio. >> Controllato da AVG - www.avg.com >> Versione: 10.0.1204 / Database dei virus: 1435/3407 - Data di rilascio: >> 27/01/2011 >> >> >> >
