Hi Dan, I solved the last problem copying libraries (xmlsec-1.3.0.jar, wss4j-1.5.1.jar, cxr-rt-ws-securitity-2.0.2-...) from the WAR-Part to the EAR-Part: (WebContent/WEB-INF/lib -> EarContent/lib)
One Problem solved another arises: Client writes the SecurityHeader: .. <wsse:Security xmlns:wsse=" http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd " soap:mustUnderstand="1"> <wsse:UsernameToken xmlns:wsu=" http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd " wsu:Id="UsernameToken-12189822"> <wsse:Username>chef</wsse:Username> <wsse:Password Type=" http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest ">MxsuASsgtCzGlTTif0kcbqXIHxM=</wsse:Password> <wsse:Nonce>HAYlnYvfdo0dddeYXGsxdw==</wsse:Nonce> <wsu:Created>2008-07-25T11:22:20.886Z</wsu:Created> </wsse:UsernameToken> </wsse:Security> ... Server is configured with the interceptor: @InInterceptors(interceptors={ "de.mypath.WSSecurityInterceptor" }) In this class I configure 3 Interceptors: public void handleMessage(Message message) throws Fault { Map<String, Object> props = new HashMap<String, Object>(); props.put(WSHandlerConstants.ACTION, WSHandlerConstants.USERNAME_TOKEN); props.put(WSHandlerConstants.PASSWORD_TYPE, WSConstants.PW_DIGEST); props.put(WSHandlerConstants.PW_CALLBACK_CLASS, ServerPasswordCallback.class.getName()); WSS4JInInterceptor wss4jInInterceptor = new WSS4JInInterceptor(props); ValidateUserTokenInterceptor userTokenInterceptor = new ValidateUserTokenInterceptor(Phase.POST_PROTOCOL); message.getInterceptorChain().add(wss4jInInterceptor); //org.apache.cxf.binding.soap.SoapFault: No SOAPMessage DOM was found. Please enable the SAAJInInterceptor. message.getInterceptorChain().add(new SAAJInInterceptor()); message.getInterceptorChain().add(userTokenInterceptor); } UserTokenInterceptor works fine, SAAJInInterceptor is necessary otherwise excepton but now I get an exception on the wss4jInInterceptor: 25.07.2008 13:03:44 org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor handleMessage WARNUNG: Request does not contain required Security header 25.07.2008 13:03:44 org.apache.cxf.phase.PhaseInterceptorChain doIntercept INFO: Interceptor has thrown exception, unwinding now org.apache.cxf.binding.soap.SoapFault: Request does not contain required Security header. at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:153) at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:60) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208) at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:429) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1955) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1791) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:575) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135) How do I know what is wrong with my SecurityHeader? -Josef Daniel Kulp <[EMAIL PROTECTED]> 23.07.2008 14:42 Bitte antworten an [email protected] An [email protected] Kopie [EMAIL PROTECTED] Thema Re: Antwort: Re: WS-Stack Apache CXF asks for Axis2-Classes On Jul 23, 2008, at 7:24 AM, [EMAIL PROTECTED] wrote: > Hi Kevin, Lin, Daniel, Glen, > > @Daniel: Your VM-Parameters solved this problem. Thank you very much > for > your help. Yea, but it definitely shouldn't have been necessary. > @Glen: Thank you very much for your tipp, we will wait for Geronimo > 2.1.2 > and then we have Apache CXF2.0.6... Actually, CXF 2.0.8. :-) > @All: Now I have two new issues ;-) > 1) The client is written like described in > http://cwiki.apache.org/CXF20DOC/ws-security.html. For the server > part - > because of JavaEE5 - we choose > http://depressedprogrammer.wordpress.com/2007/07/31/cxf-ws-security-using-jsr-181-interceptor-annotations-xfire-migration/ > . > In the first run I added > @InInterceptors > (interceptors={ "de.myapp.WSSecurityInterceptor" }) to > the WS-Implementation-Class and nothing happend. Afterwards I had a > try > with the interface class and added the same > @InInterceptors(interceptors={ "de.myapp.WSSecurityInterceptor" }). > After this changed the class de.myapp.WSSecurityInterceptor was > accessed. > Why do I have to add @... in implementation AND interface? Not sure on that. Feel free to log a CXF bug. It should be possible to just put it on the implementation. The interface should be shareable between clients/servers and having interceptors defined on it that should just be there for the server is not a good thing. > 2) In the handleMessage(Message message) I receive after: > ... > props.put(WSHandlerConstants.PASSWORD_TYPE, > WSConstants.PW_TEXT); > props.put(WSHandlerConstants.PW_CALLBACK_CLASS, > ServerPasswordCallback.class.getName()); > > WSS4JInInterceptor wss4jInHandler = new > WSS4JInInterceptor(props); > ... > > ......................... > > Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog > at [row,col {unknown-source}]: [1,0] > at > com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOF(StreamScanner.java: > 661) > at > com.ctc.wstx.sr.BasicStreamReader.handleEOF(BasicStreamReader.java: > 2134) > at > With CXF 2.0.2, that stack could result from a BUNCH of things. We actually would get that stack if the server sent back and html error page without setting a 404 or similar. Several things can cause it. If you can tcpdump or wireshark the wire transfers to see what's going on, that would be helpful. Good news is that this changed in 2.0.5 to get a better error message. :-) --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog BGS Beratungsgesellschaft Software Systemplanung AG Niederlassung Rhein/Main Robert-Koch-Straße 41 55129 Mainz Fon: +49 (0) 6131 / 914-0 Fax: +49 (0) 6131 / 914-400 www.bgs-ag.de Geschäftssitz Mainz Registergericht Amtsgericht Mainz HRB 62 50 Aufsichtsratsvorsitzender Klaus Hellwig Vorstand Hanspeter Gau Hermann Kiefer Nils Manegold
