Hi Dan
Changed my pom to 2.2.5-SNAPSHOT:
<properties>
<cxf.version>2.2.5-SNAPSHOT</cxf.version>
</properties>
I can confirm that both issues are fixed. No exception on the client side
(CXF-2480) and when I remove the IncludeToken attribute (CXF-2479), I don't get
an exception either. My server starts successfully (which he didn't before) and
the client can successfully call him.
One question remain: I've sent a soap request without the username token (from
soapui). I'd expect that CXF throws a policy exception but it went down to the
WSS4JInInterceptor till the problem has been discovered. Is this intended?
[INFO] 20.10.2009 12:57:49 org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor
handleMessage
[INFO] WARNUNG: Request does not contain required Security header
[INFO] 20.10.2009 12:57:49 org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor
handleMessage
[INFO] WARNUNG:
[INFO] org.apache.ws.security.WSSecurityException: An error was discovered
processing the <wsse:Security> header
[INFO] at
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:219)
[INFO] at
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:77)
[INFO] at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
[INFO] at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:104)
[INFO] at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:302)
[INFO] at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:266)
[INFO] at
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70)
Thanks for the fixes
Oliver
________________________________
Von: Daniel Kulp [mailto:[email protected]]
Gesendet: Mo 19.10.2009 18:21
An: [email protected]
Cc: Oliver Wulff
Betreff: Re: AW: WS-SecurityPolicy, UsernamePassword example
Oliver:
https://issues.apache.org/jira/browse/CXF-2479
https://issues.apache.org/jira/browse/CXF-2480
I'm testing fixes for both now. Should have them committed by the end of the
day.
Dan
On Mon October 19 2009 11:33:45 am Daniel Kulp wrote:
> Oliver,
>
> On Mon October 19 2009 10:36:30 am Oliver Wulff wrote:
> > Hi there
> >
> > Here are some more information how to reproduce the three issues:
> >
> > Issue 1)
> > i) mvn -Pserver
> > ii) mvn -Psecure.client
>
> This looks like a potentially over-aggressive optimization on our part.
> Need to dig in more, but it looks like if there ISN'T a security header at
> all in the response, we just skip processing entirely, which in this case
> shouldn't be done. Will dig in a bit more shortly.
>
> > Issue 2)
> > i) comment out the two dependencies in the pom.xml:
> > <dependency>
> > <groupId>org.apache.cxf</groupId>
> > <artifactId>cxf-rt-ws-security</artifactId>
> > <version>${cxf.version}</version>
> > </dependency>
> > <dependency>
> > <groupId>org.apache.cxf</groupId>
> > <artifactId>cxf-rt-ws-policy</artifactId>
> > <version>${cxf.version}</version>
> > </dependency>
> > ii) mvn -Pserver
> > iii) mvn -Psecure.client
> >
> > You see first on the client side that username/password (WS-Sec
> > UsernameToken profile) is not added to the request:
>
> If you comment out those deps, there isn't any policy engine or anything
> installed into the CXF runtime. Thus, any policies in the wsdl are
> completely ignored. This is pretty much expected and as designed.
>
> > Issue 3)
> > i) remove the attribute IncludeToken in the wsdl wsdl\hello_world.wsdl:
> > sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/Inc
> >lu deToken/Always" ii) mvn -Pserver
> >
> > The server throws the following exception during startup:
> >
> > [INFO] Caused by: java.lang.RuntimeException: Incorrect inclusion value:
> > null [INFO] at
> >
> > org.apache.cxf.ws.security.policy.model.Token.setInclusion(Token.java:63)
> >
> > IMHO, the bug is here:
> > String attribute = element.getAttributeNS(element.getNamespaceURI(),
> > SPConstants.ATTR_INCLUDE_TOKEN); The method "getAttributeNS" shouldn't
> > return an empty string.
>
> This is definitely a bug. If getAttributeNS returns null, we definitely
> should be setting it to the correct default value. (../Always)
>
--
Daniel Kulp
[email protected]
http://www.dankulp.com/blog
