RPC Style Web Service and SSL

Question

Hi,
Has anyone tried (and maybe succeeded) in accessing an
RPC-style Web Service deployed on WebLogic Server 6.1 using
SSL? I have a Web Service deployed and am able to access it using JNDI and the
weblogic.soap.http.SoapInitialContextFactory
INITIAL_CONTEXT_FACTORY. However, when I try to set the
Context.SECURITY_PROTOCOL to "ssl" and access the secure port,
I get a "java.net.SocketException: Unexpected end of file from
the server" error message.
Does the weblogic.soap.http.SoapInitialContextFactory not
support SSL? Do I need to do the SOAP/XML messaging myself,
without being able to make use of the WebLogic convenience
classes? Thanks! Rob

Answer 1

Alright!
Glad you got it working ;-)
Actually, the problem with the protocol being hardcoded to http in the wsdl.jsp,
is a bit strange. It's unusual that the BEA engineers that coded the wsgen component
and support classes, didn't use something like the following:
<soap:address location="<%= request.getScheme() + "://" + request.getServerName()
+ ":" + request.getServerPort() %>/security/examples/webservices/security/PhoneBookService"/>
I don't use wsgen too much, because I need to have more control over the J2EE
packaging. It (wsgen) is great for spitting out stuff, but not really setup for
doing Web service packaging that use classes (i.e. helper files, frameworks, etc.)
that it doesn't generate. I think they (BEA) might be looking into integrating
the Web Services assembly process with other tools like WebGain, Forte, etc. to
alleviate these types of issues.
Anyway, glad you got it working, so now you can help somebody else (time permitting,
of course) with this topic in the future!
Regards,
Mike Wooten
"Rob Nelson" <[email protected]> wrote:
>
Mike,
Thank you very much for your response! The next to
last sentence did it for me (when you mentioned checking
that the location attribute of the soap:address element
was set properly)! I noticed that when I viewed the WSDL
file via the browser (by clicking on the link in the
index.html page), I saw http://host:<unsecure_port> when
I requested it over the unsecure port, but I saw
http://host:<secure_port> when I requested the WSDL over
the secure port. Notice it did not say https!
So, I unjarred the EAR file that was generated by my
wsgen task, and then unjarred the generated WAR file
contained therein. When I looked at wsdl.jsp, I noticed
that "http" was hard-coded in the location attribute, but
that the host name and port number were dynamically
generated. So I added a scriplet to dynamically place an
"s" after "http" (if request.isSecure()) and rejarred up
the WAR and EAR files.
Now when I deployed the EAR file, I see "https" when
I request the WSDL over the secure port, and my client
(actually your client;) works! Awesome! I really appreciate
your help! Now my only issue is why did the wsdl.jsp have
"http" hard-coded, not accounting for secure requests.
These files were generated by the WSGEN task in ANT.
I figure it's either: I have a configuration problem,
I have a problem with my ANT build script, my version of
WebLogic Server (6.1 w/SP1 built 9/18/2001) has a bug, or
maybe you just have to manually go in and modify the wsdl.jsp
file if you want to use https :(. Please let me know if
you have any insight on this, and I will also follow up
with WebLogic support. Thanks again! Rob
"Michael Wooten" <[email protected]> wrote:
Hi Rob,
I am absolutely sure the code I posted works, so we need to approach
this from
a different angle ;-)
First, I know why the Context.SECURITY_PROTOCOL approach doesn't works.
It's because
the namespace in the Web Services code examples is not the same oneas
the one
used for RMI objects, EJBs, JDBC Data Sources, etc. For those objects,
the Context.PROVIDER_URL
is something like "t3://localhost:7001", and the INITIAL_CONTEXT_FACTORY
is "weblogic.jndi.WLInitialContextFactory".
The one being used with WebLogic Web Services, is mainly just functioning
as a
mechanism for manufacturing WebServiceProxy objects, because it is a
non-instanciable!
It does this by using a subclass of javax.naming.Context called SOAPContext,
which
is completely hidden from you, but also doesn't do much except implement
the lookup()
method. The implementation of this method ignores the Context.SECURITY_URL
property,
but it does pay attention to the "java.naming.security.principal" and
"java.naming.security.credentials"
properties. You don't need these properties for SSL, just Basic Authentication.
Enough about that, though. The service end-point is a servlet right?
So this means
it has a URL that begins with http or https, which in turn means the
WebLogic
servlet engine gets the SOAP request and sends it to the StatelessSessionAdapter
servlet. To WLS, this is just like any other HTTP/HTTPS request sent
to it ;-)
There is no special "SOAP-related" HTTP/HTTPS handler in WLS, but the
SSL challenge
dance still happens. So my first question is, are you sure you havethe
HTTPS
attributes set properly in the WebLogic console. SSL/HTTPS should be
enabled and
the "Hostname Verification Ignored" checkbox should be checked. Next,
are you
sure the URL assigned to the location attribute of the <service> element
in the
WSDL is correct (i.e. https://localhost:7002)? Are you using the "dynamic
client"
approach?
Regards,
Mike Wooten
"Rob Nelson" <[email protected]> wrote:
Mike,
Thanks for your response. I downloaded the code example that
you
posted
last week, as well as the code example that you posted in October for
a similar
request (BEA Support pointed me towards that). Unfortunately, I still
can't get
the Web Service to respond to the client request when the client uses
the HTTPS
port for the WebLogic Server.
I tried two different client approaches. The first uses the client
code
that you posted in October, the WebServiceProxy approach. The second
approach
is based on the example in the WebLogic documentation, which uses the
weblogic.soap.SoapInitialContextFactory
class with the javax.naming.Context object to perform a lookup on the
service
(which closely resembles rmi without the narrowing).
Both client classes fail to invoke the the service itself viaHTTPS
(although
they both work when making HTTP requests to the unsecure port). However,
when
I run the client based on the client class that you posted in October
and make
an HTTPS request, I can see in the output where it is able to download
the WSDL
file and use it (via the WebServiceProxy) to describe the availablemethods
for
the associated Web Service. It is only when the actual invoke() method
is called
on the SoapMethod object (which in turn sends the XML request to the
Web Service
Servlet), that the server doesn't respond, and the client fails with
an UnexpectedEndOfFileException
(i.e. no response).
So, do you know why the servlet that the RPC-style Web Serviceuses
to handle
requests would not respond to HTTPS requests, when it processes HTTP
requests
without a problem (using the same client code that fails with the HTTPS
request)?
I am using WebLogic Server 6.1 w/SP1 on a Solaris 8 platform. Thanks
for any
advice you can give me! Rob
"Michael Wooten" <[email protected]> wrote:
Hi Rob,
Check out the attached zip for "insights" into how to do this. It
contains
the
code for two Web service "consumers" (that the new fangled word fora
"client")
and the web.xml and weblogic.xml for the RPC-style Web Service, that
they consume.
Hope this helps,
Mike Wooten
"Rob Nelson" <[email protected]> wrote:
Hi,
Has anyone tried (and maybe succeeded) in accessing an
RPC-style Web Service deployed on WebLogic Server 6.1 using
SSL? I have a Web Service deployed and am able to access it using
JNDI
and the
weblogic.soap.http.SoapInitialContextFactory
INITIAL_CONTEXT_FACTORY. However, when I try to set the
Context.SECURITY_PROTOCOL to "ssl" and access the secure port,
I get a "java.net.SocketException: Unexpected end of file from
the server" error message.
Does the weblogic.soap.http.SoapInitialContextFactory not
support SSL? Do I need to do the SOAP/XML messaging myself,
without being able to make use of the WebLogic convenience
classes? Thanks! Rob