You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by conficio <Ka...@Conficio.com> on 2009/10/01 19:50:32 UTC
CXFServlet over https
I need to operate my web service over ssl secured https. The service works
fine over http, the overall app works fine over https. I have so far only
configured the tomcat for https://myserver.example.com:8443/
The recommended config
http://cwiki.apache.org/CXF20DOC/client-http-transport.html I don't
understand as it seems to hard code the URLs for the service which I avoid
by using the CXFServlet. It also seems to configure the keystore again,
duplicating things that are already done in tomcat. And in addition the
example does refer to authenticating via tls over ssl and I don't do that.
The service authendicated to our app via WS-I Base profile Interceptors.
Here is the behavior that I can't get around:
The CXFServlet from 2.0.11 does serve its top level list of services under
the URL https://myserver.example.com:8443/soap-services/
However, the URLS to the WSDL for each service is not https:// ==>
http://myserver.example.com:8443/soap-services/my-service?wsdl and when I
click on the link it does offer to save a binary file.
When I manually request
https://myserver.example.com:8443/soap-services/my-service?wsdl I get the
file but it's <soap:address
location="http://myserver.example.com:8443/soap-services/my-service"/> is
http again and that fails to import then any xsd files.
Any idea what to do to work around this?
--
View this message in context: http://www.nabble.com/CXFServlet-over-https-tp25703630p25703630.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXFServlet over https
Posted by conficio <Ka...@Conficio.com>.
Glen Mazza wrote:
>
> The CXF documentation is (unfortunately) present at two URLs for some
> reason, and the one you're looking at is much older. This is the better
> location (with the correct data):
> http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html
>
> It is accessible, along with all the other up-to-date pages, here:
> http://cxf.apache.org/docs/index.html
>
> ...
>
Thanks Glen, the newer documentation has the info obviously corrected.
However, the core issue of the CXFServlet serving the WSDL only partially
adapted to the https connection remains. Even if I correct the link URL the
WSDL file does have includes for the xsd files that are still named http://
So my attempt to create my service like
new UserApiService(serviceUrl);
fails.
If I try the suggestion from the bottom of the doc to set the port myself, I
get another Exception
UserApiService userService = new UserApiService();
// You can add whatever address as you want
userService.addPort(UserApiService.UserApiPort,
"http://schemas.xmlsoap.org/soap/", service);
userApi = userService.getUserApiPort();
OR
UserApiService userService = new UserApiService();
// You can add whatever address as you want
userApi = userService.getUserApiPort();
BindingProvider provider = (BindingProvider) userApi;
// You can set the address per request here
provider.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
service);
----
Oct 2, 2009 9:44:43 AM org.apache.cxf.transport.https.SSLUtils
getCiphersFromList
INFO: The cipher suites have been set to SSL_RSA_WITH_RC4_128_MD5,
SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA,
SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5,
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_KRB5_WITH_RC4_128_SHA,
TLS_KRB5_WITH_RC4_128_MD5, TLS_KRB5_WITH_3DES_EDE_CBC_SHA,
TLS_KRB5_WITH_3DES_EDE_CBC_MD5, TLS_KRB5_WITH_DES_CBC_SHA,
TLS_KRB5_WITH_DES_CBC_MD5, TLS_KRB5_EXPORT_WITH_RC4_40_SHA,
TLS_KRB5_EXPORT_WITH_RC4_40_MD5, TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA,
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5.
Oct 2, 2009 9:44:44 AM org.apache.cxf.phase.PhaseInterceptorChain
doIntercept
INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.binding.soap.SoapFault: "http://schemas.xmlsoap.org/wsdl/",
the namespace on the "definitions" element, is not a valid SOAP version.
at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:95)
at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:57)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:226)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:619)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2058)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1936)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1862)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:598)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:226)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:449)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:231)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:117)
at $Proxy28.getUsers(Unknown Source)
Any ideas how to get around this?
--
View this message in context: http://www.nabble.com/CXFServlet-over-https-tp25703630p25716368.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXFServlet over https
Posted by Glen Mazza <gl...@gmail.com>.
conficio wrote:
>
>
> conficio wrote:
>> The recommended config
>> http://cwiki.apache.org/CXF20DOC/client-http-transport.html
>
> Below the conduit config it says >>The first thing to notice is the "id"
> attribute on <http:conduit>. This allows CXF to associate this HTTP
> Conduit configuration with a particular WSDL Port. The id includes the
> service's namespace, the WSDL port name, and ".http-conduit". It follows
> this template: "{serviceNamespace}portName.http-conduit".>>
>
> But in the config code there is no "id" attribute, but only a "name"
> attribute.
>
The CXF documentation is (unfortunately) present at two URLs for some
reason, and the one you're looking at is much older. This is the better
location (with the correct data):
http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html
It is accessible, along with all the other up-to-date pages, here:
http://cxf.apache.org/docs/index.html
When I try to alter the older page you linked to, for some reason it gives
me the correct, recent "name" text (even though it displays as the older
"id"). I don't know the solution--somehow cwiki.apache.org needs to be
refreshed.
Thanks,
Glen
--
View this message in context: http://www.nabble.com/CXFServlet-over-https-tp25703630p25705304.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXFServlet over https
Posted by conficio <Ka...@Conficio.com>.
conficio wrote:
> The recommended config
> http://cwiki.apache.org/CXF20DOC/client-http-transport.html
Below the conduit config it says >>The first thing to notice is the "id"
attribute on <http:conduit>. This allows CXF to associate this HTTP Conduit
configuration with a particular WSDL Port. The id includes the service's
namespace, the WSDL port name, and ".http-conduit". It follows this
template: "{serviceNamespace}portName.http-conduit".>>
But in the config code there is no "id" attribute, but only a "name"
attribute.
--
View this message in context: http://www.nabble.com/CXFServlet-over-https-tp25703630p25704393.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXFServlet over https
Posted by Daniel Kulp <dk...@apache.org>.
The security stuff for the http:conduit and stuff is client side stuff.
Basically, how the client would talk to your server. That wouldn't apply
here where you are on the server side and are using tomcat to secure things.
In that case, you would need to configure a <security-contraints> section in
your web.xml to make sure only https connections are allowed into the
endpoints. THat's definitely not my area, but I THINK it would look
something like:
<security-constraint>
<web-resource-collection>
<web-resource-name>services</web-resource-name>
<url-pattern>/services/*</url-pattern>
<http-method>DELETE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
Dan
On Thu October 1 2009 1:50:32 pm conficio wrote:
> I need to operate my web service over ssl secured https. The service works
> fine over http, the overall app works fine over https. I have so far only
> configured the tomcat for https://myserver.example.com:8443/
>
> The recommended config
> http://cwiki.apache.org/CXF20DOC/client-http-transport.html I don't
> understand as it seems to hard code the URLs for the service which I avoid
> by using the CXFServlet. It also seems to configure the keystore again,
> duplicating things that are already done in tomcat. And in addition the
> example does refer to authenticating via tls over ssl and I don't do that.
> The service authendicated to our app via WS-I Base profile Interceptors.
>
> Here is the behavior that I can't get around:
>
> The CXFServlet from 2.0.11 does serve its top level list of services under
> the URL https://myserver.example.com:8443/soap-services/
>
> However, the URLS to the WSDL for each service is not https:// ==>
> http://myserver.example.com:8443/soap-services/my-service?wsdl and when I
> click on the link it does offer to save a binary file.
>
> When I manually request
> https://myserver.example.com:8443/soap-services/my-service?wsdl I get the
> file but it's <soap:address
> location="http://myserver.example.com:8443/soap-services/my-service"/> is
> http again and that fails to import then any xsd files.
>
> Any idea what to do to work around this?
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog