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/IncludeToken/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-wssecur
> ity-secext-1.0.xsd"
>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri
> 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-toke
> 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
