https for wsdl

[bimargulies]

Fred's email caught my eye. How hard would this be? What's involved?

[dkulp]

On Jul 23, 2008, at 8:09 AM, Benson Margulies wrote:
> Fred's email caught my eye. How hard would this be? What's involved?

Depends on how you want to implement it.   :-)

If you want to reuse the existing http-conduit configuration so that  
the configuration can be shared between the wsdl retrieval and the  
endpoint that uses it, it's quite a bit of work.   Part of the reason  
is that the conduit configuration is always based on the endpoint  
qname, which isn't something we have when retrieving the wsdl.     The  
original thought was to have a WSDLLocator that would grab the conduit  
factories from the bus and have it find the appropriate for the URL  
and create a full conduit.   Thus, you could actually retrieve wsdl  
based any transport.  (like jms)  However, that doesn't work anyway as  
the WSDLQueryHandler is only called from the HTTP stuff anyway.

The simplest solution would be to modify the  
"ResourceManagerWSDLLocator" to catch the exceptions when calling the  
parent.getBaseInputSource() and then call into the  
ResourceResolvers.    If that then fails, then retrhow the  
exception.    The user could then register a ResourceResolver to  
handle their own https requirements (or any other requirement).    If  
we do this, the http transport could immediately register an  
Implementation that would handle https based on the configuration it  
knows about.

For the configuration, we currently have something like:
   <http:conduit name="{http://apache.org/ 
hello_world_soap_http}SoapPort.http-conduit">
     <http:tlsClientParameters disableCNCheck="true">
         ...........
     </http:tlsClientParameters>
    </http:conduit>

We could extend it for this case to allow something like:


   <http:conduit name="https://my.server.com/webservices/services/MyService?wsdl 
">
     <http:tlsClientParameters disableCNCheck="true">
         ...........
     </http:tlsClientParameters>
    </http:conduit>

   <http:conduit
        name="{http://apache.org/hello_world_soap_http}SoapPort.http-
conduit"
        ref="#https://my.server.com/webservices/services/MyService?wsdl"/>

or similar such that we can name a conduit configuration based on the  
wsdl URL (instead of just an endpoint qname) and allow conduits to ref  
one another to link things together (to avoid copying blocks of  
configuration.     This would actually allow several endpoints to  
share a configuration as well without resorting to the wildcards and  
such.




---
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

[Glen Mazza]

Benson Margulies-5 wrote:

Fred's email caught my eye. How hard would this be? What's involved?

I'm not sure of the scope of what is being talked about here--Fred brought up multiple issues.

If it is the case about being able to retrieve a WSDL from an https:// URL when running wsdl2java, Metro has an option[1] called "-xauthfile" -- perhaps we should do something similar.

Glen

[1] https://jax-ws.dev.java.net/nonav/2.1.4/docs/wsimport.html

[Glen Mazza]

dkulp wrote:

We could extend it for this case to allow something like:

   <http:conduit name="https://my.server.com/webservices/services/MyService?wsdl">

Although I may be way off in what is being discussed here, I'm not sure if that will work, because the servlet container won't let you access the servlet until you have provided the basic auth username and password, so any servlet-logic such as the above would never be activated, correct?  I believe there's a Java Authenticator class that can be used instead:  http://www.nabble.com/Re%3A-How-to-pass-authetication-to-a-web-service...-p16686141.html

Again, this is assuming (20% chance) that I'm talking about what you're talking about.

Glen

[Benson Margulies-4]

I believe that the first problem at hand is using ?wsdl over https.
The tools client can't be a big deal, insofar as users can get around
it with 'wget'. At least, that's how I read Dan's comments about a
possible approach to some code.

On Wed, Jul 23, 2008 at 11:52 PM, Glen Mazza <glen.mazza@...> wrote:

>
>
> dkulp wrote:
>>
>> We could extend it for this case to allow something like:
>>
>>    <http:conduit
>> name="https://my.server.com/webservices/services/MyService?wsdl">
>>
>>
>
> Although I may be way off in what is being discussed here, I'm not sure if
> that will work, because the servlet container won't let you access the
> servlet until you have provided the basic auth username and password, so any
> servlet-logic such as the above would never be activated, correct?  I
> believe there's a Java Authenticator class that can be used instead:
> http://www.nabble.com/Re%3A-How-to-pass-authetication-to-a-web-service...-p16686141.html
>
> Again, this is assuming (20% chance) that I'm talking about what you're
> talking about.
>
> Glen
>
> --
> View this message in context: http://www.nabble.com/https-for-wsdl-tp18609319p18625023.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
>

[Benson Margulies-4]

Considering ?js as well, would it make sense to just treat a URL as
covering everything inside of it in the configuration? So, thus,
#https://my.server.com/webservices/services would work for all the
services (and wsdl files (and javascript files)) inside of that space,
unless something more specific was configured to override it?

On Wed, Jul 23, 2008 at 10:55 AM, Daniel Kulp <dkulp@...> wrote:

>
> On Jul 23, 2008, at 8:09 AM, Benson Margulies wrote:
>>
>> Fred's email caught my eye. How hard would this be? What's involved?
>
> Depends on how you want to implement it.   :-)
>
> If you want to reuse the existing http-conduit configuration so that the
> configuration can be shared between the wsdl retrieval and the endpoint that
> uses it, it's quite a bit of work.   Part of the reason is that the conduit
> configuration is always based on the endpoint qname, which isn't something
> we have when retrieving the wsdl.     The original thought was to have a
> WSDLLocator that would grab the conduit factories from the bus and have it
> find the appropriate for the URL and create a full conduit.   Thus, you
> could actually retrieve wsdl based any transport.  (like jms)  However, that
> doesn't work anyway as the WSDLQueryHandler is only called from the HTTP
> stuff anyway.
>
> The simplest solution would be to modify the "ResourceManagerWSDLLocator" to
> catch the exceptions when calling the parent.getBaseInputSource() and then
> call into the ResourceResolvers.    If that then fails, then retrhow the
> exception.    The user could then register a ResourceResolver to handle
> their own https requirements (or any other requirement).    If we do this,
> the http transport could immediately register an Implementation that would
> handle https based on the configuration it knows about.
>
> For the configuration, we currently have something like:
>  <http:conduit
> name="{http://apache.org/hello_world_soap_http}SoapPort.http-conduit">
>    <http:tlsClientParameters disableCNCheck="true">
>        ...........
>    </http:tlsClientParameters>
>   </http:conduit>
>
> We could extend it for this case to allow something like:
>
>
>  <http:conduit
> name="https://my.server.com/webservices/services/MyService?wsdl">
>    <http:tlsClientParameters disableCNCheck="true">
>        ...........
>    </http:tlsClientParameters>
>   </http:conduit>
>
>  <http:conduit
>       name="{http://apache.org/hello_world_soap_http}SoapPort.http-conduit"
>        ref="#https://my.server.com/webservices/services/MyService?wsdl"/>
>
> or similar such that we can name a conduit configuration based on the wsdl
> URL (instead of just an endpoint qname) and allow conduits to ref one
> another to link things together (to avoid copying blocks of configuration.
>   This would actually allow several endpoints to share a configuration as
> well without resorting to the wildcards and such.
>
>
>
>
> ---
> Daniel Kulp
> dkulp@...
> http://www.dankulp.com/blog
>
>
>
>
>