cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Engelschmidt ...@zama.org>
Subject Re: Problem with ws security in 2.1.3, works with 2.1.2
Date Fri, 06 Feb 2009 17:57:10 GMT
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.
>


Mime
View raw message