You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Tom.R" <to...@us.army.mil> on 2009/02/06 17:45:34 UTC
Re: Problem with ws security in 2.1.3, works with 2.1.2
I still can't resolve this error...
================
Outbound Interceptor:
================
public class WSSEHeaderOutInterceptor implements SoapInterceptor {
@Override
public Set<URI> getRoles() {
return null;
}
@Override
public Set<QName> getUnderstoodHeaders() {
Set<QName> headers = new HashSet<QName>(1);
headers.add(QName.valueOf("{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security"));
return headers;
}
@Override
public void handleFault(SoapMessage arg0) {}
@Override
public void handleMessage(SoapMessage message) throws Fault {}
}
/** This is for doing custom filtering on a
message.getExchange().containsKey(...)
public class CustomOutInterceptor extends AbstractPhaseInterceptor<Message>
public CustomOutInterceptor() {
super(Phase.PRE_STREAM);
addBefore(StaxOutInterceptor.class.getName());
}
}
===========================
My Interceptor chain is set like so:
===========================
<jaxws:outInterceptors>
<ref bean="customOutInterceptor"/>
<ref bean="wsseHeaderOutInterceptor"/>
</jaxws:outInterceptors>
I have also switched the above order to no avail. When using SAML
Assertion... I have no problems whatsoever. It is only when using
UsernameToken.
========
ERROR:
========
org.apache.cxf.phase.PhaseInterceptorChain doIntercept
INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers:
[{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security]
are not understood.
at
org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:177)
at
org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:151)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:78)
at
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:92)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:285)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:168)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:175)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.java:153)
Any ideas would be greatly appreciated.
Thanks,
-Tom
dkulp wrote:
>
>
> Basically, with 2.1.3, we are properly enforcing any MustUnderstand
> markers on
> the headers. SOMETHING on the chain needs to make sure the header is
> handled. Basically, you would need an out interceptor that subclasses
> the
> SoapInterceptor and have it's getUnderstoodHeaders() method return the
> security header qname. The interceptor doesn't need to do anything
> really,
> just marks itself has handling that header.
>
> That said, for client side, if the header is marked for the ultimate
> receiver
> role, then a must understand shouldn't trigger an exception as the
> receiver
> is the client. I'll fix that.
>
>
> Dan
>
>
> On Wednesday 21 January 2009 1:25:16 pm Thomas Engelschmidt wrote:
>> Hi,
>>
>> I'm trying to migrate a working WS-Client using cxf 2.1.2 to 2.1.3.
>>
>> The Client only uses WSS for request, therefore only a
>> WSS4JOutInterceptor with the following actions is configured:
>>
>> Action : Timestamp Signature UsernameToken
>>
>> This client work fine using cxf 2.1.2, but under cxf 2.1.3 it fails
>> with an MustUnderstand headers fault. I suppose the problem is that
>> I'm not using an WSS InInterceptors.
>>
>> How can i get around this issue without using an WSS4JInInterceptor ?
>>
>>
>> Using :
>> wsdl2java option : -client
>> spring
>> jdk 1.6 10
>>
>> btw, my reason for upgrading to 2.1.3
>> http://www.nabble.com/CXF-and-Java-6-Update-10-td19463818.html
>>
>>
>> Stacktrace :
>>
>> javax.xml.ws.soap.SOAPFaultException: MustUnderstand headers:
>> [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext
>>-1.0.xsd }Security] are not understood.
>> at
>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:145)
>> at $Proxy57.getIndkomstOplysningKlassiskAbonnentHentI(Unknown
>> Source)
>> at
>> dk.dst.eindkomst.client.IOKAhandler.bestilDataImpl(IOKAhandler.java:126)
>> at
>> dk
>> .dst
>> .eindkomst.client.EindkomstHandler.bestilData(EindkomstHandler.java:57)
>> at
>> dk.dst.eindkomst.client.SoapClient.startEIndkomst(SoapClient.java:31)
>> at dk.dst.eindkomst.client.SoapClient.main(SoapClient.java:16)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun
>> .reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
>> 39)
>> at
>> sun
>> .reflect
>> .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
>> 25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at
>> com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
>> Caused by: org.apache.cxf.binding.soap.SoapFault: MustUnderstand
>> headers:
>> [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext
>>-1.0.xsd }Security] are not understood.
>> at
>> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor
>> $
>> UltimateReceiverMustUnderstandInterceptor
>> .handleMessage(MustUnderstandInterceptor.java:177)
>> at
>> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor
>> $
>> UltimateReceiverMustUnderstandInterceptor
>> .handleMessage(MustUnderstandInterceptor.java:151)
>> at
>> org
>> .apache
>> .cxf
>> .phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220)
>> at
>> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:633)
>> at org.apache.cxf.transport.http.HTTPConduit
>> $WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2064)
>> at org.apache.cxf.transport.http.HTTPConduit
>> $WrappedOutputStream.handleResponse(HTTPConduit.java:1942)
>> at org.apache.cxf.transport.http.HTTPConduit
>> $WrappedOutputStream.close(HTTPConduit.java:1867)
>> at
>> org
>> .apache
>> .cxf
>> .io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:
>> 47)
>> at
>> org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:170)
>> at
>> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
>> at
>> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:595)
>> at org.apache.cxf.interceptor.MessageSenderInterceptor
>> $
>> MessageSenderEndingInterceptor
>> .handleMessage(MessageSenderInterceptor.java:62)
>> at
>> org
>> .apache
>> .cxf
>> .phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220)
>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:
>> 466)
>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:
>> 299)
>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:
>> 251)
>> at
>> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
>> at
>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
>> ... 10 more
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
>
--
View this message in context: http://www.nabble.com/Problem-with-ws-security-in-2.1.3%2C-works-with-2.1.2-tp21589164p21876219.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem with ws security in 2.1.3, works with 2.1.2
Posted by "Tom.R" <to...@us.army.mil>.
Thomas,
Thank you so much!!! This was the "magic bullet" I needed. It works
successfully.
Thanks,
Tom
Thomas Engelschmidt wrote:
>
> I have resolved this.
>
> You should extend
> org.apache.cxf.binding.soap.interceptor.AbstractSoapInterceptor
>
> and from AbstractWSS4JInterceptor, grap the following code
> private static final Set<QName> HEADERS = new HashSet<QName>();
> static {
> HEADERS.add(new QName(WSConstants.WSSE_NS, "Security"));
> HEADERS.add(new QName(WSConstants.WSSE11_NS, "Security"));
> HEADERS.add(new QName(WSConstants.ENC_NS, "EncryptedData"));
> }
>
> and return the HEADERS from the getUnderstoodHeaders() method.
>
> cheers
>
> Thomas
>
>
> On Feb 6, 2009, at 17:45 , Tom.R wrote:
>
>>
>> I still can't resolve this error...
>>
>> ================
>> Outbound Interceptor:
>> ================
>> public class WSSEHeaderOutInterceptor implements SoapInterceptor {
>>
>> @Override
>> public Set<URI> getRoles() {
>> return null;
>> }
>>
>> @Override
>> public Set<QName> getUnderstoodHeaders() {
>> Set<QName> headers = new HashSet<QName>(1);
>>
>> headers.add(QName.valueOf("{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> }Security"));
>>
>> return headers;
>> }
>>
>> @Override
>> public void handleFault(SoapMessage arg0) {}
>>
>> @Override
>> public void handleMessage(SoapMessage message) throws Fault {}
>> }
>>
>> /** This is for doing custom filtering on a
>> message.getExchange().containsKey(...)
>> public class CustomOutInterceptor extends
>> AbstractPhaseInterceptor<Message>
>> public CustomOutInterceptor() {
>> super(Phase.PRE_STREAM);
>> addBefore(StaxOutInterceptor.class.getName());
>> }
>> }
>>
>> ===========================
>> My Interceptor chain is set like so:
>> ===========================
>>
>> <jaxws:outInterceptors>
>> <ref bean="customOutInterceptor"/>
>> <ref bean="wsseHeaderOutInterceptor"/>
>> </jaxws:outInterceptors>
>>
>> I have also switched the above order to no avail. When using SAML
>> Assertion... I have no problems whatsoever. It is only when using
>> UsernameToken.
>>
>> ========
>> ERROR:
>> ========
>> org.apache.cxf.phase.PhaseInterceptorChain doIntercept
>> INFO: Interceptor has thrown exception, unwinding now
>> org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers:
>> [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> }Security]
>> are not understood.
>> at
>> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor
>> $
>> UltimateReceiverMustUnderstandInterceptor
>> .handleMessage(MustUnderstandInterceptor.java:177)
>> at
>> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor
>> $
>> UltimateReceiverMustUnderstandInterceptor
>> .handleMessage(MustUnderstandInterceptor.java:151)
>> at
>> org
>> .apache
>> .cxf
>> .phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:
>> 220)
>> at
>> org
>> .apache
>> .cxf
>> .transport
>> .ChainInitiationObserver.onMessage(ChainInitiationObserver.java:78)
>> at
>> org
>> .apache
>> .cxf
>> .transport.servlet.ServletDestination.invoke(ServletDestination.java:
>> 92)
>> at
>> org
>> .apache
>> .cxf
>> .transport
>> .servlet.ServletController.invokeDestination(ServletController.java:
>> 285)
>> at
>> org
>> .apache
>> .cxf
>> .transport.servlet.ServletController.invoke(ServletController.java:
>> 168)
>> at
>> org
>> .apache
>> .cxf
>> .transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:
>> 175)
>> at
>> org
>> .apache
>> .cxf
>> .transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.java:
>> 153)
>>
>> Any ideas would be greatly appreciated.
>>
>> Thanks,
>> -Tom
>>
>>
>> dkulp wrote:
>>>
>>>
>>> Basically, with 2.1.3, we are properly enforcing any MustUnderstand
>>> markers on
>>> the headers. SOMETHING on the chain needs to make sure the header
>>> is
>>> handled. Basically, you would need an out interceptor that
>>> subclasses
>>> the
>>> SoapInterceptor and have it's getUnderstoodHeaders() method return
>>> the
>>> security header qname. The interceptor doesn't need to do anything
>>> really,
>>> just marks itself has handling that header.
>>>
>>> That said, for client side, if the header is marked for the ultimate
>>> receiver
>>> role, then a must understand shouldn't trigger an exception as the
>>> receiver
>>> is the client. I'll fix that.
>>>
>>>
>>> Dan
>>>
>>>
>>> On Wednesday 21 January 2009 1:25:16 pm Thomas Engelschmidt wrote:
>>>> Hi,
>>>>
>>>> I'm trying to migrate a working WS-Client using cxf 2.1.2 to 2.1.3.
>>>>
>>>> The Client only uses WSS for request, therefore only a
>>>> WSS4JOutInterceptor with the following actions is configured:
>>>>
>>>> Action : Timestamp Signature UsernameToken
>>>>
>>>> This client work fine using cxf 2.1.2, but under cxf 2.1.3 it fails
>>>> with an MustUnderstand headers fault. I suppose the problem is that
>>>> I'm not using an WSS InInterceptors.
>>>>
>>>> How can i get around this issue without using an
>>>> WSS4JInInterceptor ?
>>>>
>>>>
>>>> Using :
>>>> wsdl2java option : -client
>>>> spring
>>>> jdk 1.6 10
>>>>
>>>> btw, my reason for upgrading to 2.1.3
>>>> http://www.nabble.com/CXF-and-Java-6-Update-10-td19463818.html
>>>>
>>>>
>>>> Stacktrace :
>>>>
>>>> javax.xml.ws.soap.SOAPFaultException: MustUnderstand headers:
>>>> [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext
>>>> -1.0.xsd }Security] are not understood.
>>>> at
>>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
>>>> 145)
>>>> at
>>>> $Proxy57.getIndkomstOplysningKlassiskAbonnentHentI(Unknown
>>>> Source)
>>>> at
>>>> dk
>>>> .dst.eindkomst.client.IOKAhandler.bestilDataImpl(IOKAhandler.java:
>>>> 126)
>>>> at
>>>> dk
>>>> .dst
>>>> .eindkomst
>>>> .client.EindkomstHandler.bestilData(EindkomstHandler.java:57)
>>>> at
>>>> dk.dst.eindkomst.client.SoapClient.startEIndkomst(SoapClient.java:
>>>> 31)
>>>> at dk.dst.eindkomst.client.SoapClient.main(SoapClient.java:
>>>> 16)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>> Method)
>>>> at
>>>> sun
>>>> .reflect
>>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
>>>> 39)
>>>> at
>>>> sun
>>>> .reflect
>>>> .DelegatingMethodAccessorImpl
>>>> .invoke(DelegatingMethodAccessorImpl.java:
>>>> 25)
>>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>> at
>>>> com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
>>>> Caused by: org.apache.cxf.binding.soap.SoapFault: MustUnderstand
>>>> headers:
>>>> [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext
>>>> -1.0.xsd }Security] are not understood.
>>>> at
>>>> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor
>>>> $
>>>> UltimateReceiverMustUnderstandInterceptor
>>>> .handleMessage(MustUnderstandInterceptor.java:177)
>>>> at
>>>> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor
>>>> $
>>>> UltimateReceiverMustUnderstandInterceptor
>>>> .handleMessage(MustUnderstandInterceptor.java:151)
>>>> at
>>>> org
>>>> .apache
>>>> .cxf
>>>> .phase
>>>> .PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220)
>>>> at
>>>> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:633)
>>>> at org.apache.cxf.transport.http.HTTPConduit
>>>> $WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2064)
>>>> at org.apache.cxf.transport.http.HTTPConduit
>>>> $WrappedOutputStream.handleResponse(HTTPConduit.java:1942)
>>>> at org.apache.cxf.transport.http.HTTPConduit
>>>> $WrappedOutputStream.close(HTTPConduit.java:1867)
>>>> at
>>>> org
>>>> .apache
>>>> .cxf
>>>> .io
>>>> .CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:
>>>> 47)
>>>> at
>>>> org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:
>>>> 170)
>>>> at
>>>> org
>>>> .apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
>>>> at
>>>> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:
>>>> 595)
>>>> at org.apache.cxf.interceptor.MessageSenderInterceptor
>>>> $
>>>> MessageSenderEndingInterceptor
>>>> .handleMessage(MessageSenderInterceptor.java:62)
>>>> at
>>>> org
>>>> .apache
>>>> .cxf
>>>> .phase
>>>> .PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220)
>>>> at
>>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:
>>>> 466)
>>>> at
>>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:
>>>> 299)
>>>> at
>>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:
>>>> 251)
>>>> at
>>>> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
>>>> at
>>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
>>>> 124)
>>>> ... 10 more
>>>
>>>
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://dankulp.com/blog
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Problem-with-ws-security-in-2.1.3%2C-works-with-2.1.2-tp21589164p21876219.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>
>
>
--
View this message in context: http://www.nabble.com/Problem-with-ws-security-in-2.1.3%2C-works-with-2.1.2-tp21589164p21905155.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem with ws security in 2.1.3, works with 2.1.2
Posted by Thomas Engelschmidt <te...@zama.org>.
I have resolved this.
You should extend
org.apache.cxf.binding.soap.interceptor.AbstractSoapInterceptor
and from AbstractWSS4JInterceptor, grap the following code
private static final Set<QName> HEADERS = new HashSet<QName>();
static {
HEADERS.add(new QName(WSConstants.WSSE_NS, "Security"));
HEADERS.add(new QName(WSConstants.WSSE11_NS, "Security"));
HEADERS.add(new QName(WSConstants.ENC_NS, "EncryptedData"));
}
and return the HEADERS from the getUnderstoodHeaders() method.
cheers
Thomas
On Feb 6, 2009, at 17:45 , Tom.R wrote:
>
> I still can't resolve this error...
>
> ================
> Outbound Interceptor:
> ================
> public class WSSEHeaderOutInterceptor implements SoapInterceptor {
>
> @Override
> public Set<URI> getRoles() {
> return null;
> }
>
> @Override
> public Set<QName> getUnderstoodHeaders() {
> Set<QName> headers = new HashSet<QName>(1);
>
> headers.add(QName.valueOf("{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> }Security"));
>
> return headers;
> }
>
> @Override
> public void handleFault(SoapMessage arg0) {}
>
> @Override
> public void handleMessage(SoapMessage message) throws Fault {}
> }
>
> /** This is for doing custom filtering on a
> message.getExchange().containsKey(...)
> public class CustomOutInterceptor extends
> AbstractPhaseInterceptor<Message>
> public CustomOutInterceptor() {
> super(Phase.PRE_STREAM);
> addBefore(StaxOutInterceptor.class.getName());
> }
> }
>
> ===========================
> My Interceptor chain is set like so:
> ===========================
>
> <jaxws:outInterceptors>
> <ref bean="customOutInterceptor"/>
> <ref bean="wsseHeaderOutInterceptor"/>
> </jaxws:outInterceptors>
>
> I have also switched the above order to no avail. When using SAML
> Assertion... I have no problems whatsoever. It is only when using
> UsernameToken.
>
> ========
> ERROR:
> ========
> org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> INFO: Interceptor has thrown exception, unwinding now
> org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers:
> [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> }Security]
> are not understood.
> at
> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor
> $
> UltimateReceiverMustUnderstandInterceptor
> .handleMessage(MustUnderstandInterceptor.java:177)
> at
> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor
> $
> UltimateReceiverMustUnderstandInterceptor
> .handleMessage(MustUnderstandInterceptor.java:151)
> at
> org
> .apache
> .cxf
> .phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:
> 220)
> at
> org
> .apache
> .cxf
> .transport
> .ChainInitiationObserver.onMessage(ChainInitiationObserver.java:78)
> at
> org
> .apache
> .cxf
> .transport.servlet.ServletDestination.invoke(ServletDestination.java:
> 92)
> at
> org
> .apache
> .cxf
> .transport
> .servlet.ServletController.invokeDestination(ServletController.java:
> 285)
> at
> org
> .apache
> .cxf
> .transport.servlet.ServletController.invoke(ServletController.java:
> 168)
> at
> org
> .apache
> .cxf
> .transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:
> 175)
> at
> org
> .apache
> .cxf
> .transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.java:
> 153)
>
> Any ideas would be greatly appreciated.
>
> Thanks,
> -Tom
>
>
> dkulp wrote:
>>
>>
>> Basically, with 2.1.3, we are properly enforcing any MustUnderstand
>> markers on
>> the headers. SOMETHING on the chain needs to make sure the header
>> is
>> handled. Basically, you would need an out interceptor that
>> subclasses
>> the
>> SoapInterceptor and have it's getUnderstoodHeaders() method return
>> the
>> security header qname. The interceptor doesn't need to do anything
>> really,
>> just marks itself has handling that header.
>>
>> That said, for client side, if the header is marked for the ultimate
>> receiver
>> role, then a must understand shouldn't trigger an exception as the
>> receiver
>> is the client. I'll fix that.
>>
>>
>> Dan
>>
>>
>> On Wednesday 21 January 2009 1:25:16 pm Thomas Engelschmidt wrote:
>>> Hi,
>>>
>>> I'm trying to migrate a working WS-Client using cxf 2.1.2 to 2.1.3.
>>>
>>> The Client only uses WSS for request, therefore only a
>>> WSS4JOutInterceptor with the following actions is configured:
>>>
>>> Action : Timestamp Signature UsernameToken
>>>
>>> This client work fine using cxf 2.1.2, but under cxf 2.1.3 it fails
>>> with an MustUnderstand headers fault. I suppose the problem is that
>>> I'm not using an WSS InInterceptors.
>>>
>>> How can i get around this issue without using an
>>> WSS4JInInterceptor ?
>>>
>>>
>>> Using :
>>> wsdl2java option : -client
>>> spring
>>> jdk 1.6 10
>>>
>>> btw, my reason for upgrading to 2.1.3
>>> http://www.nabble.com/CXF-and-Java-6-Update-10-td19463818.html
>>>
>>>
>>> Stacktrace :
>>>
>>> javax.xml.ws.soap.SOAPFaultException: MustUnderstand headers:
>>> [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext
>>> -1.0.xsd }Security] are not understood.
>>> at
>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
>>> 145)
>>> at
>>> $Proxy57.getIndkomstOplysningKlassiskAbonnentHentI(Unknown
>>> Source)
>>> at
>>> dk
>>> .dst.eindkomst.client.IOKAhandler.bestilDataImpl(IOKAhandler.java:
>>> 126)
>>> at
>>> dk
>>> .dst
>>> .eindkomst
>>> .client.EindkomstHandler.bestilData(EindkomstHandler.java:57)
>>> at
>>> dk.dst.eindkomst.client.SoapClient.startEIndkomst(SoapClient.java:
>>> 31)
>>> at dk.dst.eindkomst.client.SoapClient.main(SoapClient.java:
>>> 16)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>> Method)
>>> at
>>> sun
>>> .reflect
>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
>>> 39)
>>> at
>>> sun
>>> .reflect
>>> .DelegatingMethodAccessorImpl
>>> .invoke(DelegatingMethodAccessorImpl.java:
>>> 25)
>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>> at
>>> com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
>>> Caused by: org.apache.cxf.binding.soap.SoapFault: MustUnderstand
>>> headers:
>>> [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext
>>> -1.0.xsd }Security] are not understood.
>>> at
>>> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor
>>> $
>>> UltimateReceiverMustUnderstandInterceptor
>>> .handleMessage(MustUnderstandInterceptor.java:177)
>>> at
>>> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor
>>> $
>>> UltimateReceiverMustUnderstandInterceptor
>>> .handleMessage(MustUnderstandInterceptor.java:151)
>>> at
>>> org
>>> .apache
>>> .cxf
>>> .phase
>>> .PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220)
>>> at
>>> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:633)
>>> at org.apache.cxf.transport.http.HTTPConduit
>>> $WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2064)
>>> at org.apache.cxf.transport.http.HTTPConduit
>>> $WrappedOutputStream.handleResponse(HTTPConduit.java:1942)
>>> at org.apache.cxf.transport.http.HTTPConduit
>>> $WrappedOutputStream.close(HTTPConduit.java:1867)
>>> at
>>> org
>>> .apache
>>> .cxf
>>> .io
>>> .CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:
>>> 47)
>>> at
>>> org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:
>>> 170)
>>> at
>>> org
>>> .apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
>>> at
>>> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:
>>> 595)
>>> at org.apache.cxf.interceptor.MessageSenderInterceptor
>>> $
>>> MessageSenderEndingInterceptor
>>> .handleMessage(MessageSenderInterceptor.java:62)
>>> at
>>> org
>>> .apache
>>> .cxf
>>> .phase
>>> .PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220)
>>> at
>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:
>>> 466)
>>> at
>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:
>>> 299)
>>> at
>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:
>>> 251)
>>> at
>>> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
>>> at
>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
>>> 124)
>>> ... 10 more
>>
>>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Problem-with-ws-security-in-2.1.3%2C-works-with-2.1.2-tp21589164p21876219.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
Re: Problem with ws security in 2.1.3, works with 2.1.2
Posted by Daniel Kulp <dk...@apache.org>.
I believe the WSSEHeaderOutInterceptor needs to be an "In" interceptor.
Basically, the issue is that the incoming message has a security header, but
nothing there that says it will process it.
Dan
On Fri February 6 2009 11:45:34 am Tom.R wrote:
> I still can't resolve this error...
>
> ================
> Outbound Interceptor:
> ================
> public class WSSEHeaderOutInterceptor implements SoapInterceptor {
>
> @Override
> public Set<URI> getRoles() {
> return null;
> }
>
> @Override
> public Set<QName> getUnderstoodHeaders() {
> Set<QName> headers = new HashSet<QName>(1);
>
> headers.add(QName.valueOf("{http://docs.oasis-open.org/wss/2004/01/oasis-20
>0401-wss-wssecurity-secext-1.0.xsd}Security"));
>
> return headers;
> }
>
> @Override
> public void handleFault(SoapMessage arg0) {}
>
> @Override
> public void handleMessage(SoapMessage message) throws Fault {}
> }
>
> /** This is for doing custom filtering on a
> message.getExchange().containsKey(...)
> public class CustomOutInterceptor extends AbstractPhaseInterceptor<Message>
> public CustomOutInterceptor() {
> super(Phase.PRE_STREAM);
> addBefore(StaxOutInterceptor.class.getName());
> }
> }
>
> ===========================
> My Interceptor chain is set like so:
> ===========================
>
> <jaxws:outInterceptors>
> <ref bean="customOutInterceptor"/>
> <ref bean="wsseHeaderOutInterceptor"/>
> </jaxws:outInterceptors>
>
> I have also switched the above order to no avail. When using SAML
> Assertion... I have no problems whatsoever. It is only when using
> UsernameToken.
>
> ========
> ERROR:
> ========
> org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> INFO: Interceptor has thrown exception, unwinding now
> org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers:
> [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext
>-1.0.xsd}Security] are not understood.
> at
> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateR
>eceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.jav
>a:177) at
> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateR
>eceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.jav
>a:151) at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai
>n.java:220) at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationO
>bserver.java:78) at
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestinati
>on.java:92) at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(Servle
>tController.java:285) at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController
>.java:168) at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServl
>et.java:175) at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServl
>et.java:153)
>
> Any ideas would be greatly appreciated.
>
> Thanks,
> -Tom
>
> dkulp wrote:
> > Basically, with 2.1.3, we are properly enforcing any MustUnderstand
> > markers on
> > the headers. SOMETHING on the chain needs to make sure the header is
> > handled. Basically, you would need an out interceptor that subclasses
> > the
> > SoapInterceptor and have it's getUnderstoodHeaders() method return the
> > security header qname. The interceptor doesn't need to do anything
> > really,
> > just marks itself has handling that header.
> >
> > That said, for client side, if the header is marked for the ultimate
> > receiver
> > role, then a must understand shouldn't trigger an exception as the
> > receiver
> > is the client. I'll fix that.
> >
> >
> > Dan
> >
> > On Wednesday 21 January 2009 1:25:16 pm Thomas Engelschmidt wrote:
> >> Hi,
> >>
> >> I'm trying to migrate a working WS-Client using cxf 2.1.2 to 2.1.3.
> >>
> >> The Client only uses WSS for request, therefore only a
> >> WSS4JOutInterceptor with the following actions is configured:
> >>
> >> Action : Timestamp Signature UsernameToken
> >>
> >> This client work fine using cxf 2.1.2, but under cxf 2.1.3 it fails
> >> with an MustUnderstand headers fault. I suppose the problem is that
> >> I'm not using an WSS InInterceptors.
> >>
> >> How can i get around this issue without using an WSS4JInInterceptor ?
> >>
> >>
> >> Using :
> >> wsdl2java option : -client
> >> spring
> >> jdk 1.6 10
> >>
> >> btw, my reason for upgrading to 2.1.3
> >> http://www.nabble.com/CXF-and-Java-6-Update-10-td19463818.html
> >>
> >>
> >> Stacktrace :
> >>
> >> javax.xml.ws.soap.SOAPFaultException: MustUnderstand headers:
> >> [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-sec
> >>ext -1.0.xsd }Security] are not understood.
> >> at
> >> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:145)
> >> at $Proxy57.getIndkomstOplysningKlassiskAbonnentHentI(Unknown
> >> Source)
> >> at
> >> dk.dst.eindkomst.client.IOKAhandler.bestilDataImpl(IOKAhandler.java:126)
> >> at
> >> dk
> >> .dst
> >> .eindkomst.client.EindkomstHandler.bestilData(EindkomstHandler.java:57)
> >> at
> >> dk.dst.eindkomst.client.SoapClient.startEIndkomst(SoapClient.java:31)
> >> at dk.dst.eindkomst.client.SoapClient.main(SoapClient.java:16)
> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> at
> >> sun
> >> .reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> >> 39)
> >> at
> >> sun
> >> .reflect
> >> .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
> >> 25)
> >> at java.lang.reflect.Method.invoke(Method.java:597)
> >> at
> >> com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
> >> Caused by: org.apache.cxf.binding.soap.SoapFault: MustUnderstand
> >> headers:
> >> [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-sec
> >>ext -1.0.xsd }Security] are not understood.
> >> at
> >> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor
> >> $
> >> UltimateReceiverMustUnderstandInterceptor
> >> .handleMessage(MustUnderstandInterceptor.java:177)
> >> at
> >> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor
> >> $
> >> UltimateReceiverMustUnderstandInterceptor
> >> .handleMessage(MustUnderstandInterceptor.java:151)
> >> at
> >> org
> >> .apache
> >> .cxf
> >> .phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220)
> >> at
> >> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:633)
> >> at org.apache.cxf.transport.http.HTTPConduit
> >> $WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2064)
> >> at org.apache.cxf.transport.http.HTTPConduit
> >> $WrappedOutputStream.handleResponse(HTTPConduit.java:1942)
> >> at org.apache.cxf.transport.http.HTTPConduit
> >> $WrappedOutputStream.close(HTTPConduit.java:1867)
> >> at
> >> org
> >> .apache
> >> .cxf
> >> .io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:
> >> 47)
> >> at
> >> org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:170)
> >> at
> >> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
> >> at
> >> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:595)
> >> at org.apache.cxf.interceptor.MessageSenderInterceptor
> >> $
> >> MessageSenderEndingInterceptor
> >> .handleMessage(MessageSenderInterceptor.java:62)
> >> at
> >> org
> >> .apache
> >> .cxf
> >> .phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220)
> >> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:
> >> 466)
> >> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:
> >> 299)
> >> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:
> >> 251)
> >> at
> >> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> >> at
> >> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
> >> ... 10 more
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog