You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Ingo <wo...@gmail.com> on 2015/06/02 18:21:20 UTC
Re: Exception when trying to retrieve/process a WSDL via WS-MEX
Dear Colm,
sorry for the delayed catchup, but in the meanwhile I found the time to
debug the scenario and figured out the *root cause* *of the exception*,
which I wanted to share, since it was NOT simple...
The setup of the cross_domain
<https://github.com/apache/cxf/blob/master/services/sts/systests/advanced/src/test/resources/org/apache/cxf/systest/sts/cross_domain>
systest was modified by myself in such way, that:
* BSTS configuration was applied to the cxf sts-service
<https://github.com/apache/cxf/blob/master/services/sts/sts-war>
* BSTS got equipped with the WS-SecurityPolicy of the original cross_domain
systest
* Transport Security configuration (keystore, truststore, https port) was
*handled by the servlet container*
* BSTS war file is deployed in a servlet container (e.g. Tomcat or Jetty)
There are differences in the jaxws:endpoint address property:
/cross_domain systest/ -->
address="https://localhost:30102/SecurityTokenService/b" (see here
<https://github.com/apache/cxf/blob/master/services/sts/systests/advanced/src/test/resources/org/apache/cxf/systest/sts/cross_domain/cxf-sts-saml2.xml#L64>
)
compared to
/sts service /sts-war/ --> address="/b" (in the style of this configuration
<https://github.com/apache/cxf/blob/master/services/sts/sts-war/src/main/webapp/WEB-INF/cxf-transport.xml#L50>
)
...that strike through the *MEX response of BSTS* when running the test with
BSTS deployed in Tomcat.
Instead of having the correct, absolute service endpoint URL of the original
test:
only the relative address part is included in the MEX response:This leads to
the initially mentioned exception during runtime configuration of the
sts-client, since the comparison of the MEX response and the
WS-SecurityPolicy (issuer address) of the service
<https://github.com/apache/cxf/blob/master/services/sts/systests/advanced/src/test/resources/org/apache/cxf/systest/sts/cross_domain/DoubleIt.wsdl#L161>
gives no match.
Is there a way to "repair" the MEX response of the SecurityTokenService when
having it deployed to a container?
Should this be seen as a bug of the CXF WS-MEX implementation?
best regards,
Ingo
--
View this message in context: http://cxf.547215.n5.nabble.com/Exception-when-trying-to-retrieve-process-a-WSDL-via-WS-MEX-tp5750835p5757894.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Exception when trying to retrieve/process a WSDL via WS-MEX
Posted by Ingo <wo...@gmail.com>.
Hi Colm,
thank you for the prompt response. I checked out the latest 3.1.1-SNAPSHOT
from the master branch, built the war, deployed it to Tomcat 7
and voilá the issue is *resolved*.
I was working before with sts service from the CXF 3.0.2 release facing that
bug.
cheers with compliments,
Ingo
--
View this message in context: http://cxf.547215.n5.nabble.com/Exception-when-trying-to-retrieve-process-a-WSDL-via-WS-MEX-tp5750835p5757947.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Exception when trying to retrieve/process a WSDL via WS-MEX
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Ingo,
Yes, that sounds like a bug, however I can't reproduce it. This is what I
did with the latest CXF 3.0.x branch code:
I built the STS war including in the CXF distribution including WS-MEX ->
services/sts/sts-war: mvn clean install -Pcxf25
Copied the resulting war to a Tomcat 7 instance.
I've added a unit test as part of this commit to download the WSDL via
WS-MEX:
https://git1-us-west.apache.org/repos/asf?p=cxf.git;a=commit;h=02c588ce
So I just modified the port number to correspond to the port that Tomcat
was running on, and looked at the output of the WSDL (printed in the
console, if you turn on logging to INFO + enable the ConsoleHandler):
<wsdl:port binding="wstrust:Transport_Binding" name="Transport_Port">
<soap:address location="
http://localhost:8080/SecurityTokenService/Transport"/>
</wsdl:port>
Could you try again with the latest CXF code to see if the problem
persists? If it does, then maybe adapt this test-case with your WAR to see
whether the returned address is correct or not? If it is incorrect, then
please send me the updated war + I can try running it.
Colm.
On Tue, Jun 2, 2015 at 5:21 PM, Ingo <wo...@gmail.com> wrote:
> Dear Colm,
> sorry for the delayed catchup, but in the meanwhile I found the time to
> debug the scenario and figured out the *root cause* *of the exception*,
> which I wanted to share, since it was NOT simple...
>
> The setup of the cross_domain
> <
> https://github.com/apache/cxf/blob/master/services/sts/systests/advanced/src/test/resources/org/apache/cxf/systest/sts/cross_domain
> >
> systest was modified by myself in such way, that:
> * BSTS configuration was applied to the cxf sts-service
> <https://github.com/apache/cxf/blob/master/services/sts/sts-war>
> * BSTS got equipped with the WS-SecurityPolicy of the original cross_domain
> systest
> * Transport Security configuration (keystore, truststore, https port) was
> *handled by the servlet container*
> * BSTS war file is deployed in a servlet container (e.g. Tomcat or Jetty)
>
> There are differences in the jaxws:endpoint address property:
>
> /cross_domain systest/ -->
> address="https://localhost:30102/SecurityTokenService/b" (see here
> <
> https://github.com/apache/cxf/blob/master/services/sts/systests/advanced/src/test/resources/org/apache/cxf/systest/sts/cross_domain/cxf-sts-saml2.xml#L64
> >
> )
>
> compared to
>
> /sts service /sts-war/ --> address="/b" (in the style of this
> configuration
> <
> https://github.com/apache/cxf/blob/master/services/sts/sts-war/src/main/webapp/WEB-INF/cxf-transport.xml#L50
> >
> )
>
> ...that strike through the *MEX response of BSTS* when running the test
> with
> BSTS deployed in Tomcat.
>
> Instead of having the correct, absolute service endpoint URL of the
> original
> test:
> only the relative address part is included in the MEX response:This leads
> to
> the initially mentioned exception during runtime configuration of the
> sts-client, since the comparison of the MEX response and the
> WS-SecurityPolicy (issuer address) of the service
> <
> https://github.com/apache/cxf/blob/master/services/sts/systests/advanced/src/test/resources/org/apache/cxf/systest/sts/cross_domain/DoubleIt.wsdl#L161
> >
> gives no match.
>
> Is there a way to "repair" the MEX response of the SecurityTokenService
> when
> having it deployed to a container?
> Should this be seen as a bug of the CXF WS-MEX implementation?
>
> best regards,
> Ingo
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Exception-when-trying-to-retrieve-process-a-WSDL-via-WS-MEX-tp5750835p5757894.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com