cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: WS-SecurityPolicy in CXF 2.1.x, or just 2.2?
Date Mon, 06 Oct 2008 12:42:19 GMT
On Sunday 05 October 2008, Glen Mazza wrote:
> Hello, having just watched my Buffalo Bills get clobbered, 

The AFC east is definitely proving to be quite interesting this year.   
The predicted top two teams now have major injury issues, Favre is 
resurecting the Jets, and Dolphins are surprisingly good.  While things 
don't look good for the Pats without Brady, it still should be a fun 
season to watch with everything going on. 

> I would 
> next like to test out the WS-SecurityPolicy configuration that Dan has
> done.  Is it supported only on the CXF 2.2 branch or both 2.1.x and
> 2.2?  

Just 2.2.   It's very "unstable" right now as I kind of move things 
around to get it working.   Right now, there is pretty much no error 
handling (it likely will just printStackTrace and continue with 
unpredicatble results), I'll probably refactory the sending into 3 (or 
more) interceptors, and the incoming messages are currently not 
validated against the policies.  Basically, there is still much work to 
do, but it's at a state where the basic usecases are working.  The MS 
InteropFest usecases are now working (except the UsernameToken stuff, 
and I'm not sure why yet.  Seems MS wants those encrypted, even if the 
policy says not to, but I haven't dug into all that yet.  Not having a 
windows box is slightly hindering that progress.)

> Also, is there any client-side WSDL configuration or is it just 
> service-side WSDL config?  

Actually, the CLIENT side stuff is MUCH better tested right now.   I've 
been using the live MS WCF tests at:
as my testcases.   For the most part, I just run wsdl2java on the wsdls 
and have a simple client that calls on them.   For each "test case", the 
spring config sets the properties that are needed.     For example, I 

Turn on the policy stuff:  (this will probably be the default for 2.2 if 
it all works and doesn't affect performance)

Configure the client:  (wsssec 1.1 testcases, symetric binding, x509 

            <entry key="ws-security.callback-handler" 
            <entry key="ws-security.encryption.username" value="Bob"/>
            <entry key="" 

Or:  (wssec 1.0 testcases, asymetric binding)


            <entry key="ws-security.username" value="Alice"/>
            <entry key="ws-security.callback-handler" 
            <entry key="" 
            <entry key="ws-security.encryption.username" value="Bob"/>
            <entry key="" 

There is a file in the ws/security module that 
defines the various constants that the runtime will look for.   They can 
be configured into the client (or endpoint on the server side) via 
spring config like above, but you can also use the JAX-WS request 
context.   For example:


Thus, other than turning on the Policy stuff on the bus, it's quite 
usable without any configuration at all.  

> I would think it is just service-side, 
> because we use normal WSS4J config files for the client-side (and
> service-side) key/password info, if I'm not mistaken.

For the crypto stuff, yea.   We use the normal Merlin config files, but 
thats for both server and client side.  Not quite sure what the best way 
to deal with that.  Feel free to offer suggestions.   :-)

HOWEVER, the runtime for the sending side (not the incoming side yet), 
will grab a Crypto object out of the message context if available.   
Thus, if you build up a Crypto object somehow else, (feature, other 
interceptor, stick in the RequestContext, etc...), it will use it.  
Thus, if you have some really good ideas, we can implement it ahead of 
the Policy out interceptors.


> Thanks,
> Glen

J. Daniel Kulp

View raw message