You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by ext2 <xu...@tongtech.com> on 2011/06/14 04:37:26 UTC

Bean Processor cause WS Security Failure

Hi:

	Following is a simple sayHello Webservice implemented by camel. 
	<from uri="cxf:endpointHello:..."/>
	<bean ref=".." method="..."/>
	The webservice's request is configured to decrypt by server
certificate and response is configured to encrypt by client certificate.

	If I use a bean as following, every thing is ok
		helloBean{
			void sayHello(Exchange ex){
				ex.getOut().setBody("hello");
			}
		}
	;

	But using following bean , response encryption will failed.
	HelloBean{
		String sayHello(String greet){
			return "hello";
		}
	}

	the reason is the second bean will propagate headers(also include
security header) from cxf request, it is conflicted with response security.
But the first bean doesn't propagate headers;

	Is it issue of bean processor? cxf component? Or just a document FAQ
to caution the user to filter the security header by himself?




Re: Bean Processor cause WS Security Failure

Posted by ext2 <xu...@tongtech.com>.
Thanks Willem
It's the WS-Security header;
//soap 12
QName wsseQName = new QName(WSConstants.WSSE_NS, WSConstants.WSSE_LN); 
//soap 11
QName wsse11QName = new QName(WSConstants.WSSE11_NS, WSConstants.WSSE_LN); 

When security is enabled, we filter it. Then everything is ok.



> -----original -----
> Sender: Willem Jiang [mailto:willem.jiang@gmail.com]
> Date: 2011年6月14日 11:31
> Receiver: users@camel.apache.org
> Subject: Re: Bean Processor cause WS Security Failure
> 
> What's request security header name ?
> Maybe we can consider to filter the security header of the CXF message
> in CxfHeaderFilterStrategy.
> You can configure your own HeaderFilterStrategy by extends the
> CxfHeaderFilterStrategy.
> 
> 
> On 6/14/11 10:37 AM, ext2 wrote:
> >
> > Hi:
> >
> > 	Following is a simple sayHello Webservice implemented by camel.
> > 	<from uri="cxf:endpointHello:..."/>
> > 	<bean ref=".." method="..."/>
> > 	The webservice's request is configured to decrypt by server
> > certificate and response is configured to encrypt by client certificate.
> >
> > 	If I use a bean as following, every thing is ok
> > 		helloBean{
> > 			void sayHello(Exchange ex){
> > 				ex.getOut().setBody("hello");
> > 			}
> > 		}
> > 	;
> >
> > 	But using following bean , response encryption will failed.
> > 	HelloBean{
> > 		String sayHello(String greet){
> > 			return "hello";
> > 		}
> > 	}
> >
> > 	the reason is the second bean will propagate headers(also include
> > security header) from cxf request, it is conflicted with response
security.
> > But the first bean doesn't propagate headers;
> >
> > 	Is it issue of bean processor? cxf component? Or just a document FAQ
> > to caution the user to filter the security header by himself?
> >
> >
> >
> >
> 
> 
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog:    http://willemjiang.blogspot.com (English)
>           http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
> Weibo: willemjiang



Re: Bean Processor cause WS Security Failure

Posted by Willem Jiang <wi...@gmail.com>.
What's request security header name ?
Maybe we can consider to filter the security header of the CXF message 
in CxfHeaderFilterStrategy.
You can configure your own HeaderFilterStrategy by extends the 
CxfHeaderFilterStrategy.


On 6/14/11 10:37 AM, ext2 wrote:
>
> Hi:
>
> 	Following is a simple sayHello Webservice implemented by camel.
> 	<from uri="cxf:endpointHello:..."/>
> 	<bean ref=".." method="..."/>
> 	The webservice's request is configured to decrypt by server
> certificate and response is configured to encrypt by client certificate.
>
> 	If I use a bean as following, every thing is ok
> 		helloBean{
> 			void sayHello(Exchange ex){
> 				ex.getOut().setBody("hello");
> 			}
> 		}
> 	;
>
> 	But using following bean , response encryption will failed.
> 	HelloBean{
> 		String sayHello(String greet){
> 			return "hello";
> 		}
> 	}
>
> 	the reason is the second bean will propagate headers(also include
> security header) from cxf request, it is conflicted with response security.
> But the first bean doesn't propagate headers;
>
> 	Is it issue of bean processor? cxf component? Or just a document FAQ
> to caution the user to filter the security header by himself?
>
>
>
>


-- 
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
          http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang