Ah. Java first. Right. That complicates things quite a bit. This will become significantly easier with CXF 2.3 as we've added annotations that can be used to attach policies to the java class/methods and such that would appear in the WSDL. But that's 2.3, not 2.2.4.
For 2.2.3, we did apply a patch that supposedly allows it: https://issues.apache.org/jira/browse/CXF-2281 but we didn't really get a test case for it some I'm not 100% sure how to configure it. Looking at the code, it LOOKS like it's only configured in via the external policy attachment spec stuff. You thus have a file like: <attachments xmlns:wsp="http://www.w3.org/ns/ws-policy"> <wsp:PolicyAttachment> <wsp:AppliesTo> <wsa:EndpointReferenceType xmlns:wsa="http://www.w3.org/2005/08/addressing"> <wsa:Address>http://x.y.z/GreeterPort</wsa:Address> </wsa:EndpointReferenceType> </wsp:AppliesTo> <wsp:Policy> ............ </wsp:Policy> </wsp:PolicyAttachment> </attachments> and then in your spring config, just add: <p:externalAttachment id="external" location="classpath:/blah/blah/attachments.xml"/> or similar. Definitely not idea and it would be good to simplify this quite a bit somehow. (of course, with 2.3, the annotations simplify it quite a bit) Dan On Tue October 20 2009 1:06:01 pm vickatvuuch wrote: > Hi Dan, > > Thanks for your reply. > > Forgot to mention that I'm building and running on CXF 2.2.4. > > Are you saying, that I can not have generated WSDL to include WSPolicy or > you are saying that if I configure it CXF will do it automagically? What > about this note on WS-SecurityPolicy? > > Note: at this point, WS-SecurityPolicy support is ONLY available for "WSDL > first" scenarios. The WS-SecurityPolicy fragments can only be pulled from > WSDL. In the future, we plan to enable various code first scenarios as > well, but at this time, only WSDL first is available. > > http://cxf.apache.org/docs/ws-securitypolicy.html > > I already tried to specify policy as follows: > > <wsp:Policy wsu:Id="UsernameToken" > > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri > ty-utility-1.0.xsd"> <wsp:ExactlyOne> > <wsp:All> > <sp:SupportingTokens > xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"> > <wsp:Policy> > <sp:UsernameToken > sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ > IncludeToken/AlwaysToRecipient" /> > </wsp:Policy> > </sp:SupportingTokens> > </wsp:All> > </wsp:ExactlyOne> > </wsp:Policy> > > <jaxws:endpoint implementor="#helloWorldServiceBean" > address="/v1/soap/HelloWorld"> > <jaxws:features> > <p:policies> > <wsp:PolicyReference URI="#UsernameToken" > xmlns:wsp="http://www.w3.org/2006/07/ws-policy" /> > </p:policies> > > </jaxws:features> > > </jaxws:endpoint> > > java2ws produced the same WSDL as before - no traces of policy. > > dkulp wrote: > > On Tue October 20 2009 11:28:59 am vickatvuuch wrote: > >> Hi All, > >> > >> I'm trying to put together a java first CXF server with WS-Security. > >> I have the WSS4JInInterceptor with password callback handling my > >> requests with clear text pass for now. > >> Could somebody point me into a right direction regarding two issues I'm > >> trying to figure out: > >> 1. WSDL header generation, in particular how to add WS-Security header > >> to a > >> generated WSDL, any examples? > > > > Well, in general, you don't. I've never actually seen that done. > > > > For the most part, what you would do it define a WS-SecurityPolicy policy > > that > > defined the security constraints and then the various security policy > > runtimes > > would interpret that into the required security header. In your case, > > the > > summary would be a TransportBinding/HttpsToken with a UsernameToken > > SupportingToken. > > > > In XML that would be added to the wsdl, it would look like: > > > > > > <wsp:Policy wsu:Id="ut_policy" > > xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" > > > > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401- > > wss-wssecurity-utility-1.0.xsd"> > > <sp:TransportBinding > > xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> > > <wsp:Policy> > > <sp:TransportToken> > > <wsp:Policy> > > <sp:HttpsToken/> > > </wsp:Policy> > > </sp:TransportToken> > > <sp:Layout> > > <wsp:Policy> > > <sp:Strict/> > > </wsp:Policy> > > </sp:Layout> > > <sp:AlgorithmSuite> > > <wsp:Policy> > > <sp:Basic128/> > > </wsp:Policy> > > </sp:AlgorithmSuite> > > </wsp:Policy> > > </sp:TransportBinding> > > <sp:SupportingTokens > > xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> > > <wsp:Policy> > > <sp:UsernameToken > > xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" > > sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/Inc > >ludeToken/Always"> <wsp:Policy> > > <sp:WssUsernameToken11/> > > </wsp:Policy> > > </sp:UsernameToken> > > </wsp:Policy> > > </sp:SupportingTokens> > > </wsp:Policy> > > > > and then add > > <wsp:PolicyReference > > xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" > > URI="#ut_policy"/> > > > > to the wsdl:service/wsdl:port for your service. > > > > Of course, once you do that with CXF, the SecurityPolicy implementation > > will > > probably kick in and process it and you would need on unconfigure the > > WSS4J > > interceptors and reconfigure things using the SecurityPolicy constants. > > See: > > > > http://cxf.apache.org/docs/ws-securitypolicy.html > > > > for information. Oliver Wulff is kind of working on a SecurityPolicy > > based > > UsernameToken example: > > http://www.nabble.com/WS-SecurityPolicy,-UsernamePassword-example- > > to25958182.html > > > >> 2. Another question I have is how to handle sessions using CXF, can't > >> find > >> a good example on that.. Basic idea is to have a Auth port to > >> authenticate > >> a session/token using WS-Security, have server return that > >> session/token and make client use that for subsequent calls into all > >> other ports. > > > > Yea. That's definitely one way to do it. You would normally define some > > sort > > of session object in schema and then reference that schema from the other > > services and define soap:headers in those WSDL's for the sessions. > > > > Dan > > > >> Thanks, > >> -Vitaly > >> > >> Here is SOAP request with WS-Security which WSS4JInInterceptor is > >> handling. > >> > >> <soapenv:Envelope > >> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" > >> xmlns:spr="http://spring.demo/"> > >> soap:mustUnderstand="1"> > >> <soapenv:Header> > >> <wsse:Security > >> > >> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse > >>cur ity-secext-1.0.xsd" > >> > >> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssec > >>uri ty-utility-1.0.xsd" soapenv:mustUnderstand="true"> > >> <wsse:UsernameToken wsu:Id="UsernameToken-799830164"> > >> <wsse:Username>username</wsse:Username> > >> <wsse:Password > >> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-t > >>oke n-profile-1.0#PasswordText">password</wsse:Password> > >> </wsse:UsernameToken> > >> </wsse:Security> > >> </soapenv:Header> > >> > >> <soapenv:Body> > >> <spr:getDude> > >> <!--Optional:--> > >> <arg0>1</arg0> > >> <!--Optional:--> > >> <arg1>2</arg1> > >> </spr:getDude> > >> </soapenv:Body> > >> </soapenv:Envelope> > >> > >> My project is attached. > >> http://www.nabble.com/file/p25977266/CXFHelloServer.jar > >> CXFHelloServer.jar > -- Daniel Kulp [email protected] http://www.dankulp.com/blog
