You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Wu, Billy" <Bi...@stercomm.com> on 2008/09/04 21:23:39 UTC

Encrypting/Signing the Server Exception

Hi,

 

We are developing a web service using CXF 2.1.1, and we are
encrypting/signing all the inbound/outbound messages using WSS4J.
Everything works fine until when there is an exception.  When an
exception is thrown from a web service, it bypasses all the
encryption/signing, and return a soap fault back to the client in clear
text.  Here is an example,

 

<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:
Fault><faultcode>soap:Server</faultcode><faultstring>VALD001E Missing
required field [name].    VALD001E Missing required field [name].
</faultstring><detail><ns1:ValidationException
xmlns:ns1="http://service.ws.sspgui.sterlingcommerce.com/"
/></detail></soap:Fault></soap:Body></soap:Envelope>

 

However, since the client is expecting the message to be encrypted and
signed, the client will get the following without the original soap
fault message,

 

Caused by: org.apache.ws.security.WSSecurityException: An error was
discovered processing the <wsse:Security> header

      at
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JI
nInterceptor.java:168)

 

What we really want to do is for the client to catch the exception, so
it can be handled appropriately.  Does anyone know a good solution to
this issue?

 

Thanks,

 

Billy


RE: Encrypting/Signing the Server Exception

Posted by "Wu, Billy" <Bi...@stercomm.com>.
Hi everyone,

I just realized that I mistakenly put down the wrong outinterceptor to
the outfault.  My bad.  The exception is properly encrypted and signed
after I configured it properly.

Thanks,

Billy

-----Original Message-----
From: Wu, Billy [mailto:Billy_Wu@stercomm.com] 
Sent: Monday, September 08, 2008 2:20 PM
To: Daniel Kulp; users@cxf.apache.org
Subject: RE: Encrypting/Signing the Server Exception

Thanks Dan for your reply.

I just added the wss4joutinterceptor to the outfault chain, and I can
see the body gets encrypted and signed.  However, on the client side, I
am now getting the below error even after I added wss4jininterceptor to
my infaultinterceptors.  The "Unexpected EOF in prolog" error seems like
the fault message is not getting encrypted or decrypted properly.  But I
have the same set up for the regular in/out interceptors.  If the
non-fault message works, shouldn't the fault message work as well? 

Do I have to get the 2nd thing (below) to make this work?

Thanks,

Billy


Sep 8, 2008 2:04:43 PM org.apache.cxf.phase.PhaseInterceptorChain
doIntercept
INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.binding.soap.SoapFault: Error reading XMLStreamReader.
	at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMes
sage(ReadHeadersInterceptor.java:183)
	at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMes
sage(ReadHeadersInterceptor.java:54)
	at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
hain.java:221)
	at
org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:449)
	at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResp
onse(HTTPConduit.java:1996)
	at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTP
Conduit.java:1832)
	at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
	at
org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:591)
	at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingI
nterceptor.handleMessage(MessageSenderInterceptor.java:62)
	at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
hain.java:221)
	at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:296)
	at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:242)
	at
org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
	at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:178)
	at $Proxy47.listConfigObjects(Unknown Source)
	at
com.sterlingcommerce.sspgui.ws.client.ScmClient.testListing(ScmClient.ja
va:188)
	at
com.sterlingcommerce.sspgui.ws.client.ScmClient.main(ScmClient.java:133)
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
com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:
2040)
	at
com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1069)
	at
com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1095)
	at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMes
sage(ReadHeadersInterceptor.java:83)
	... 16 more
javax.xml.ws.soap.SOAPFaultException: Error reading XMLStreamReader.
	at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:199)
	at $Proxy47.listConfigObjects(Unknown Source)
	at
com.sterlingcommerce.sspgui.ws.client.ScmClient.testListing(ScmClient.ja
va:188)
	at
com.sterlingcommerce.sspgui.ws.client.ScmClient.main(ScmClient.java:133)
Caused by: org.apache.cxf.binding.soap.SoapFault: Error reading
XMLStreamReader.
	at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMes
sage(ReadHeadersInterceptor.java:183)
	at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMes
sage(ReadHeadersInterceptor.java:54)
	at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
hain.java:221)
	at
org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:449)
	at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResp
onse(HTTPConduit.java:1996)
	at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTP
Conduit.java:1832)
	at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
	at
org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:591)
	at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingI
nterceptor.handleMessage(MessageSenderInterceptor.java:62)
	at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
hain.java:221)
	at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:296)
	at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:242)
	at
org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
	at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:178)
	... 3 more
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
com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:
2040)
	at
com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1069)
	at
com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1095)
	at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMes
sage(ReadHeadersInterceptor.java:83)
	... 16 more





-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org] 
Sent: Friday, September 05, 2008 12:52 PM
To: users@cxf.apache.org
Cc: Wu, Billy
Subject: Re: Encrypting/Signing the Server Exception


 
Two things:
1) Add the wss4joutinterceptor to the outfault chain as well to get the
faults 
signed.

2) I just committed a change to the WSS4JInInterceptor to allow the on
the 
wire fault to propogate if the security checks fail.   Thus, the client
would 
get the real fault message and not the security one.

Dan 


On Thursday 04 September 2008 3:23:39 pm Wu, Billy wrote:
> Hi,
>
>
>
> We are developing a web service using CXF 2.1.1, and we are
> encrypting/signing all the inbound/outbound messages using WSS4J.
> Everything works fine until when there is an exception.  When an
> exception is thrown from a web service, it bypasses all the
> encryption/signing, and return a soap fault back to the client in
clear
> text.  Here is an example,
>
>
>
> <soap:Envelope
>
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:
> Fault><faultcode>soap:Server</faultcode><faultstring>VALD001E Missing
> required field [name].    VALD001E Missing required field [name].
> </faultstring><detail><ns1:ValidationException
> xmlns:ns1="http://service.ws.sspgui.sterlingcommerce.com/"
> /></detail></soap:Fault></soap:Body></soap:Envelope>
>
>
>
> However, since the client is expecting the message to be encrypted and
> signed, the client will get the following without the original soap
> fault message,
>
>
>
> Caused by: org.apache.ws.security.WSSecurityException: An error was
> discovered processing the <wsse:Security> header
>
>       at
>
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JI
> nInterceptor.java:168)
>
>
>
> What we really want to do is for the client to catch the exception, so
> it can be handled appropriately.  Does anyone know a good solution to
> this issue?
>
>
>
> Thanks,
>
>
>
> Billy



-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

RE: Encrypting/Signing the Server Exception

Posted by "Wu, Billy" <Bi...@stercomm.com>.
Thanks Dan for your reply.

I just added the wss4joutinterceptor to the outfault chain, and I can
see the body gets encrypted and signed.  However, on the client side, I
am now getting the below error even after I added wss4jininterceptor to
my infaultinterceptors.  The "Unexpected EOF in prolog" error seems like
the fault message is not getting encrypted or decrypted properly.  But I
have the same set up for the regular in/out interceptors.  If the
non-fault message works, shouldn't the fault message work as well? 

Do I have to get the 2nd thing (below) to make this work?

Thanks,

Billy


Sep 8, 2008 2:04:43 PM org.apache.cxf.phase.PhaseInterceptorChain
doIntercept
INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.binding.soap.SoapFault: Error reading XMLStreamReader.
	at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMes
sage(ReadHeadersInterceptor.java:183)
	at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMes
sage(ReadHeadersInterceptor.java:54)
	at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
hain.java:221)
	at
org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:449)
	at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResp
onse(HTTPConduit.java:1996)
	at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTP
Conduit.java:1832)
	at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
	at
org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:591)
	at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingI
nterceptor.handleMessage(MessageSenderInterceptor.java:62)
	at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
hain.java:221)
	at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:296)
	at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:242)
	at
org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
	at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:178)
	at $Proxy47.listConfigObjects(Unknown Source)
	at
com.sterlingcommerce.sspgui.ws.client.ScmClient.testListing(ScmClient.ja
va:188)
	at
com.sterlingcommerce.sspgui.ws.client.ScmClient.main(ScmClient.java:133)
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
com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:
2040)
	at
com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1069)
	at
com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1095)
	at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMes
sage(ReadHeadersInterceptor.java:83)
	... 16 more
javax.xml.ws.soap.SOAPFaultException: Error reading XMLStreamReader.
	at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:199)
	at $Proxy47.listConfigObjects(Unknown Source)
	at
com.sterlingcommerce.sspgui.ws.client.ScmClient.testListing(ScmClient.ja
va:188)
	at
com.sterlingcommerce.sspgui.ws.client.ScmClient.main(ScmClient.java:133)
Caused by: org.apache.cxf.binding.soap.SoapFault: Error reading
XMLStreamReader.
	at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMes
sage(ReadHeadersInterceptor.java:183)
	at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMes
sage(ReadHeadersInterceptor.java:54)
	at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
hain.java:221)
	at
org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:449)
	at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResp
onse(HTTPConduit.java:1996)
	at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTP
Conduit.java:1832)
	at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
	at
org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:591)
	at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingI
nterceptor.handleMessage(MessageSenderInterceptor.java:62)
	at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
hain.java:221)
	at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:296)
	at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:242)
	at
org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
	at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:178)
	... 3 more
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
com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:
2040)
	at
com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1069)
	at
com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1095)
	at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMes
sage(ReadHeadersInterceptor.java:83)
	... 16 more





-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org] 
Sent: Friday, September 05, 2008 12:52 PM
To: users@cxf.apache.org
Cc: Wu, Billy
Subject: Re: Encrypting/Signing the Server Exception


 
Two things:
1) Add the wss4joutinterceptor to the outfault chain as well to get the
faults 
signed.

2) I just committed a change to the WSS4JInInterceptor to allow the on
the 
wire fault to propogate if the security checks fail.   Thus, the client
would 
get the real fault message and not the security one.

Dan 


On Thursday 04 September 2008 3:23:39 pm Wu, Billy wrote:
> Hi,
>
>
>
> We are developing a web service using CXF 2.1.1, and we are
> encrypting/signing all the inbound/outbound messages using WSS4J.
> Everything works fine until when there is an exception.  When an
> exception is thrown from a web service, it bypasses all the
> encryption/signing, and return a soap fault back to the client in
clear
> text.  Here is an example,
>
>
>
> <soap:Envelope
>
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:
> Fault><faultcode>soap:Server</faultcode><faultstring>VALD001E Missing
> required field [name].    VALD001E Missing required field [name].
> </faultstring><detail><ns1:ValidationException
> xmlns:ns1="http://service.ws.sspgui.sterlingcommerce.com/"
> /></detail></soap:Fault></soap:Body></soap:Envelope>
>
>
>
> However, since the client is expecting the message to be encrypted and
> signed, the client will get the following without the original soap
> fault message,
>
>
>
> Caused by: org.apache.ws.security.WSSecurityException: An error was
> discovered processing the <wsse:Security> header
>
>       at
>
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JI
> nInterceptor.java:168)
>
>
>
> What we really want to do is for the client to catch the exception, so
> it can be handled appropriately.  Does anyone know a good solution to
> this issue?
>
>
>
> Thanks,
>
>
>
> Billy



-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

Re: Encrypting/Signing the Server Exception

Posted by Daniel Kulp <dk...@apache.org>.
 
Two things:
1) Add the wss4joutinterceptor to the outfault chain as well to get the faults 
signed.

2) I just committed a change to the WSS4JInInterceptor to allow the on the 
wire fault to propogate if the security checks fail.   Thus, the client would 
get the real fault message and not the security one.

Dan 


On Thursday 04 September 2008 3:23:39 pm Wu, Billy wrote:
> Hi,
>
>
>
> We are developing a web service using CXF 2.1.1, and we are
> encrypting/signing all the inbound/outbound messages using WSS4J.
> Everything works fine until when there is an exception.  When an
> exception is thrown from a web service, it bypasses all the
> encryption/signing, and return a soap fault back to the client in clear
> text.  Here is an example,
>
>
>
> <soap:Envelope
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:
> Fault><faultcode>soap:Server</faultcode><faultstring>VALD001E Missing
> required field [name].    VALD001E Missing required field [name].
> </faultstring><detail><ns1:ValidationException
> xmlns:ns1="http://service.ws.sspgui.sterlingcommerce.com/"
> /></detail></soap:Fault></soap:Body></soap:Envelope>
>
>
>
> However, since the client is expecting the message to be encrypted and
> signed, the client will get the following without the original soap
> fault message,
>
>
>
> Caused by: org.apache.ws.security.WSSecurityException: An error was
> discovered processing the <wsse:Security> header
>
>       at
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JI
> nInterceptor.java:168)
>
>
>
> What we really want to do is for the client to catch the exception, so
> it can be handled appropriately.  Does anyone know a good solution to
> this issue?
>
>
>
> Thanks,
>
>
>
> Billy



-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog