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: http://mssoapinterop.org/ilab/ 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 have: Turn on the policy stuff: (this will probably be the default for 2.2 if it all works and doesn't affect performance) <cxf:bus> <cxf:features> <p:policies/> <cxf:logging/> </cxf:features> </cxf:bus> Configure the client: (wsssec 1.1 testcases, symetric binding, x509 ProtectionToken) <jaxws:client name="{http://InteropBaseAddress/interop}A_IPingService"; createdFromAPI="true"> <jaxws:properties> <entry key="ws-security.callback-handler" value="interop.client.KeystorePasswordCallback"/> <entry key="ws-security.encryption.username" value="Bob"/> <entry key="ws-security.encryption.properties" value="etc/bob.properties"/> </jaxws:properties> </jaxws:client> Or: (wssec 1.0 testcases, asymetric binding) <jaxws:client name="{http://InteropBaseAddress/interop}MutualCertificate10SignEncryptRsa15TripleDes_IPingService"; createdFromAPI="true"> <jaxws:properties> <entry key="ws-security.username" value="Alice"/> <entry key="ws-security.callback-handler" value="demo.hw.client.KeystorePasswordCallback"/> <entry key="ws-security.signature.properties" value="alice.properties"/> <entry key="ws-security.encryption.username" value="Bob"/> <entry key="ws-security.encryption.properties" value="bob.properties"/> </jaxws:properties> </jaxws:client> There is a SecurityConstants.java 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: binding.getRequestContext().put("ws-security.encryption.username", "Bob"); .... 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. Dan > > Thanks, > Glen -- J. Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
