You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Oliver Wulff <ow...@progress.com> on 2009/10/19 13:42:35 UTC
WS-SecurityPolicy, UsernamePassword example
Hi there
I've created a UsernamePassword example based on WS-SecurityPolicy configurations (instead of WSS4JIn/OutInterceptor). See attachment.
I came across a few issues which I'd like to discuss with you whether these are user errors or bugs. Let me know your thoughts and I will raise the jira requests...
1) The client sends the username/password, the server verifies the password, processes the request and sends a soap message back. But the client fails with the following exception:
Caused by: org.apache.cxf.ws.policy.PolicyException: These policy alternatives can not be satisfied:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportBinding
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SupportingTokens
at org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(AssertionInfoMap.java:140)
at org.apache.cxf.ws.policy.PolicyVerificationInInterceptor.handle(PolicyVerificationInInterceptor.java:96)
at org.apache.cxf.ws.policy.AbstractPolicyInterceptor.handleMessage(AbstractPolicyInterceptor.java:45)
... 24 more
Do you know why the client fails after the response from the server is sent back? A policy exception should have been thrown before, I guess.
2) When I don't reference the following two dependencies in the POM the server and client doesn't enforce the policy which means that the client sends the request without username/password and the server accepts the request:
<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>
3) If I don't define the IncludeToken attribute in the UsernameToken policy the server fails:
[INFO] Caused by: java.lang.RuntimeException: Incorrect inclusion value: null
[INFO] at org.apache.cxf.ws.security.policy.model.Token.setInclusion(Token.java:63)
[INFO] at org.apache.cxf.ws.security.policy.builders.UsernameTokenBuilder.build(UsernameTokenBuilder.java:58)
[INFO] at org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl.build(AssertionBuilderRegistryImpl.java:110)
<sp:UsernameToken xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Always">
I debugged the code and noticed that "getAttributeNS" of class UsernameTokenBuilder returns an empty string instead of null:
String attribute = element.getAttributeNS(element.getNamespaceURI(), SPConstants.ATTR_INCLUDE_TOKEN);
if (attribute != null) {
usernameToken.setInclusion(consts.getInclusionFromAttributeValue(attribute));
}
Thanks
Oliver
AW: AW: AW: WS-SecurityPolicy, UsernamePassword example
Posted by Oliver Wulff <ow...@progress.com>.
Hi Dan
>>>
Well, I guess it depends on who you are. If you are Microsoft, for ANY
security related issues at all, they just send back a "Security token could
not be processed" fault. No description at all as to why.
>>>
I fully understand this point of view and it makes absolut sense. The soap fault should not contain more information than something like the policies could not be satisfied. IMHO, we should not give more indication which underyling processing system detected a problem (like wss4j).
On the server side it should be clear whether there is a problem with the policies or with the configuration of the server. A generic policy exception should be thrown if the policy expression could not be satisfied and returned back to the client. If CXF has been configured differently - without WS-SecurityPolicy, only plain WSS4J - we can give the wss4j message back - as it does now.
What do you think?
Thanks
Oliver
________________________________
Von: Daniel Kulp [mailto:dkulp@apache.org]
Gesendet: Di 20.10.2009 17:08
An: users@cxf.apache.org
Cc: Oliver Wulff
Betreff: Re: AW: AW: WS-SecurityPolicy, UsernamePassword example
On Tue October 20 2009 7:01:57 am Oliver Wulff wrote:
> 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.
Cool. Good news!
> 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
Well, I guess it depends on who you are. If you are Microsoft, for ANY
security related issues at all, they just send back a "Security token could
not be processed" fault. No description at all as to why. I guess it's
to hinder hackers attempts to figure out what they need to adjust before
trying again or something. However, from an testing/debugging standpoint, a
huge pain in the butt to figure out what is wrong unless you have access to
server logs.
In any case, in the absence of a Security header at all, WSS4J returns a null
result vector. If there is supposed to be one there (precomputed), we punt
immediately. Otherwise, we'd need to guard against NullPointers and such all
over. (or create a fake empty vector) Basically, it's faster (less
processing) and easier, but I could easily be convinced it should be the other
way.
Thoughts?
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: AW: AW: WS-SecurityPolicy, UsernamePassword example
Posted by Daniel Kulp <dk...@apache.org>.
On Tue October 20 2009 7:01:57 am Oliver Wulff wrote:
> 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.
Cool. Good news!
> 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
Well, I guess it depends on who you are. If you are Microsoft, for ANY
security related issues at all, they just send back a "Security token could
not be processed" fault. No description at all as to why. I guess it's
to hinder hackers attempts to figure out what they need to adjust before
trying again or something. However, from an testing/debugging standpoint, a
huge pain in the butt to figure out what is wrong unless you have access to
server logs.
In any case, in the absence of a Security header at all, WSS4J returns a null
result vector. If there is supposed to be one there (precomputed), we punt
immediately. Otherwise, we'd need to guard against NullPointers and such all
over. (or create a fake empty vector) Basically, it's faster (less
processing) and easier, but I could easily be convinced it should be the other
way.
Thoughts?
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
AW: AW: WS-SecurityPolicy, UsernamePassword example
Posted by Oliver Wulff <ow...@progress.com>.
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:dkulp@apache.org]
Gesendet: Mo 19.10.2009 18:21
An: users@cxf.apache.org
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
dkulp@apache.org
http://www.dankulp.com/blog
Re: AW: WS-SecurityPolicy, UsernamePassword example
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org
http://www.dankulp.com/blog
AW: AW: WS-SecurityPolicy, UsernamePassword example
Posted by Oliver Wulff <ow...@progress.com>.
Dan,
thanks for the feedback...
>>>
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.
>>>
I think it would make sense to either ignore it or abort if something unknown is defined. The drawback is that an invalid deployment results into an unprotected web service.
Thanks
Oliver
________________________________
Von: Daniel Kulp [mailto:dkulp@apache.org]
Gesendet: Mo 19.10.2009 17:33
An: users@cxf.apache.org
Cc: Oliver Wulff
Betreff: Re: AW: WS-SecurityPolicy, UsernamePassword example
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/Inclu
> 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
dkulp@apache.org
http://www.dankulp.com/blog
Re: AW: WS-SecurityPolicy, UsernamePassword example
Posted by Daniel Kulp <dk...@apache.org>.
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/Inclu
> 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
dkulp@apache.org
http://www.dankulp.com/blog
AW: WS-SecurityPolicy, UsernamePassword example
Posted by Oliver Wulff <ow...@progress.com>.
Hi there
Here are some more information how to reproduce the three issues:
Issue 1)
i) mvn -Pserver
ii) mvn -Psecure.client
**************************************
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:
19.10.2009 16:17:35 org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose
INFO: Outbound Message
---------------------------
ID: 1
Address: https://localhost:9001/SoapContext/SoapPort
Encoding: UTF-8
Content-Type: text/xml
Headers: {SOAPAction=[""], Authorization=[Basic Z3VndXM6aGFsbG8=], Accept=[*/*]}
Payload: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><greetMe xmlns="http://apache.org/hello_world_soap_http/types"><requestType>chzwuol</requestType></greetMe></soap:Body></soap:Envelope>
--------------------------------------
19.10.2009 16:17:35 org.apache.cxf.interceptor.LoggingInInterceptor logging
INFO: Inbound Message
----------------------------
ID: 1
Encoding: UTF-8
Content-Type: text/xml; charset=utf-8
Headers: {Content-Length=[240], Server=[Jetty(6.1.21)], content-type=[text/xml;charset=utf-8]}
Payload: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><greetMeResponse xmlns="http://apache.org/hello_world_soap_http/types"><responseType>Hello chzwuol</responseType></greetMeResponse></soap:Body></soap:Envelope>
--------------------------------------
Server responded with: Hello chzwuol
and on the server side (much more critical), no exception is thrown even the policy is defined in the wsdl:
[INFO] 19.10.2009 16:17:35 org.apache.cxf.interceptor.LoggingInInterceptor logging
[INFO] INFO: Inbound Message
[INFO] ----------------------------
[INFO] ID: 2
[INFO] Address: /SoapContext/SoapPort
[INFO] Encoding: UTF-8
[INFO] Content-Type: text/xml; charset=UTF-8
[INFO] Headers: {Content-Length=[216], Host=[localhost:9001], User-Agent=[Apache CXF 2.2.4], Authorization=[Basic Z3VndXM6aGFsbG8=], connection=[keep-alive], SO
APAction=[""], Pragma=[no-cache], Content-Type=[text/xml; charset=UTF-8], content-type=[text/xml; charset=UTF-8], Cache-Control=[no-cache], Accept=[*/*]}
[INFO] Payload: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><greetMe <http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><greetMe> xmlns="http://apache.org/hello_world_soap_http/types <http://apache.org/hello_world_soap_http/types> ">
<requestType>chzwuol</requestType></greetMe></soap:Body></soap:Envelope>
[INFO] --------------------------------------
[INFO] 19.10.2009 16:17:35 demo.hw_https.server.GreeterImpl greetMe
[INFO] [INFO] INFO: Executing operation greetMe
Executing operation greetMe
[INFO] Message received: chzwuol
[INFO]
[INFO] 19.10.2009 16:17:35 org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose
[INFO] INFO: Outbound Message
[INFO] ---------------------------
[INFO] ID: 2
[INFO] Encoding: UTF-8
[INFO] Content-Type: text/xml
[INFO] Headers: {}
[INFO] Payload: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envel <http://schemas.xmlsoap.org/soap/envel>
ope/"><soap:Body><greetMeResponse xmlns="http://apache.org/hello_world_soap_http <http://apache.org/hello_world_soap_http>
/types"><responseType>Hello chzwuol</responseType></greetMeResponse></soap:Body>
</soap:Envelope>
[INFO] --------------------------------------
***************************************************
Issue 3)
i) remove the attribute IncludeToken in the wsdl wsdl\hello_world.wsdl:
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/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)
[INFO] at org.apache.cxf.ws.security.policy.builders.UsernameTokenBuilder.build(UsernameTokenBuilder.java:58)
[INFO] at org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl.build(AssertionBuilderRegistryImpl.java:110)
[INFO] at org.apache.cxf.ws.policy.PolicyBuilderImpl.processOperationElement(PolicyBuilderImpl.java:190)
[INFO] at org.apache.cxf.ws.policy.PolicyBuilderImpl.getPolicyOperator(PolicyBuilderImpl.java:133)
[INFO] at org.apache.cxf.ws.policy.PolicyBuilderImpl.getPolicy(PolicyBuilderImpl.java:129)
[INFO] at org.apache.cxf.ws.security.policy.builders.SupportingTokensBuilder.build(SupportingTokensBuilder.java:82)
IMHO, the bug is here:
String attribute = element.getAttributeNS(element.getNamespaceURI(), SPConstants.ATTR_INCLUDE_TOKEN);
The method "getAttributeNS" shouldn't return an empty string.
Thanks
Oliver
________________________________
Von: Oliver Wulff [mailto:owulff@progress.com]
Gesendet: Mo 19.10.2009 13:42
An: users@cxf.apache.org
Betreff: WS-SecurityPolicy, UsernamePassword example
Hi there
I've created a UsernamePassword example based on WS-SecurityPolicy configurations (instead of WSS4JIn/OutInterceptor). See attachment.
I came across a few issues which I'd like to discuss with you whether these are user errors or bugs. Let me know your thoughts and I will raise the jira requests...
1) The client sends the username/password, the server verifies the password, processes the request and sends a soap message back. But the client fails with the following exception:
Caused by: org.apache.cxf.ws.policy.PolicyException: These policy alternatives can not be satisfied:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportBinding
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SupportingTokens
at org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(AssertionInfoMap.java:140)
at org.apache.cxf.ws.policy.PolicyVerificationInInterceptor.handle(PolicyVerificationInInterceptor.java:96)
at org.apache.cxf.ws.policy.AbstractPolicyInterceptor.handleMessage(AbstractPolicyInterceptor.java:45)
... 24 more
Do you know why the client fails after the response from the server is sent back? A policy exception should have been thrown before, I guess.
2) When I don't reference the following two dependencies in the POM the server and client doesn't enforce the policy which means that the client sends the request without username/password and the server accepts the request:
<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>
3) If I don't define the IncludeToken attribute in the UsernameToken policy the server fails:
[INFO] Caused by: java.lang.RuntimeException: Incorrect inclusion value: null
[INFO] at org.apache.cxf.ws.security.policy.model.Token.setInclusion(Token.java:63)
[INFO] at org.apache.cxf.ws.security.policy.builders.UsernameTokenBuilder.build(UsernameTokenBuilder.java:58)
[INFO] at org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl.build(AssertionBuilderRegistryImpl.java:110)
<sp:UsernameToken xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Always">
I debugged the code and noticed that "getAttributeNS" of class UsernameTokenBuilder returns an empty string instead of null:
String attribute = element.getAttributeNS(element.getNamespaceURI(), SPConstants.ATTR_INCLUDE_TOKEN);
if (attribute != null) {
usernameToken.setInclusion(consts.getInclusionFromAttributeValue(attribute));
}
Thanks
Oliver