xml-soap-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David B. Bitton" <da...@codenoevil.com>
Subject Re: SOAP & servlet model parallels
Date Thu, 06 Jun 2002 16:32:38 GMT
We are looking to go to a Java SOAP implementation for part of our app.  The
way I envision security is to establish a thin state machine that would
store authentication tokens.  A client would envoke an authentication method
on the server, and would be returned an authentication token.  Then for each
subsequent method invocation, the client would pass the token in the SOAP

This seems like the easiest way to implement security.  Perhaps I'm wrong.
Also, checkout SOAP Programming with Java, Bill Brogden (ISBN: 0782129285).


David B. Bitton

Code Made Fresh DailyT
----- Original Message -----
From: "Greg Symons" <gsymons@researchfed.com>
To: <soap-user@xml.apache.org>
Sent: Wednesday, June 05, 2002 4:42 PM
Subject: RE: SOAP & servlet model parallels

> On Wed, Jun 05, 2002 at 11:53:04AM -0400, Greg Symons wrote:
> > I'm kinda new to SOAP myself, but my understanding from my
> reading in
> > "Professional XML Web Services" from Wrox (ISBN:1-861005-09-1) that
> > the best way to do this is to actually just create a class that
> > implements the Provider interface and use that as a custom provider
> > for your SOAP service.
>      Can you clarify, a bit, the role a Provider has in the
> server? I've looked at the API doc for Provider, and at the
> Provider section of the User's guide at
> http://xml.apache.org/soap/docs/index.html, but they don't
> really explain how Provider fits into the bigger picture.

Hmmm... after reading the documentation more carefully, both in my book
and on the Apache-SOAP site (including some of the source code) it
appears my understanding of the Provider class was not as clear as I
thought. I initially thought that the Provider class was cleanly
separated from the SOAP protocol processing; i.e. SOAP request is posted
to the RPCRouterServlet, the servlet extracts the method name and the
parameters, and then passes those to the Provider, which would handle
loading and instantiating the class containing the method. Under that
model, you could include in the public definition of your method (WSDL
or whatever) extra parameters that don't actually get passed to the real
method, but instead are processed by the provider; e.g. you could pass a
SecurityContext parameter which the Provider would then process to make
sure that the caller was authenticated and allowed to access the actual
method... after insuring that, the Provider would then load and
instantiate the class containing the actual method, then call the method
with the real parameters. That way you could nice and neatly separate
the security logic from the actual processing. But now that I've looked
a little closer, that kind of separation doesn't really exist.

Not that that answers your question:) From what I can tell the Provider
does sit between the servlet and the class. However, it doesn't actually
call the method... it passes that off to the RPCRouter class using that
class's static invoke() method. However, you can still get the kind of
behavior I was looking for by modifying the Call object that the servlet
generates; i.e. the Call object will contain both your additional
parameters (e.g. SecurityContext) and the real parameters to the method.
Simply remove your Provider parameters from the Call before sending it
to the RPCRouter to validate the method. Store the modified Call for use
in your invoke() method. You still have to pass through a bunch of SOAP
junk, but at least you don't have to modify it. Now, I haven't tested
that way of doing things, but I think it'll work.
>      Does "Professional XML Web Services" delve much into the
> structure of the Apache SOAP server?
> > I haven't totally looked into what's involved, but looking
> briefly at
> > the docs, it seems that would be an easier way to do it,
> since you can
> > leave the RPCRouter alone, and let it extract all the call
> data out of
> > the envelope and then pass it to your provider.  Of course
> that'd mean
> > you'd have to embed any security information into the SOAP
> call itself
> > rather than using protocol level authentication, but that
> also seems
> > more extensible and flexible to me anyway.
>      I see what you mean, but I'm not entirely sure that's a
> bad thing.

I agree. Leave application-level security to the application. Doesn't
mean you can't use protocol level security, but don't try to rewrite the
protocol to do things your application should be doing.

>      When I first started thinking and reading about SOAP
> security, my first thoughts were using simple SSL tunneling
> to protect the transmission integrity, and certificate
> authentication between dedicated clients and servers to
> provide authentication.  You'd set it up once for each
> channel of communication between a given SOAP client and SOAP
> server, and as needed between that SOAP server and another
> SOAP server it might relay to.

This is partially what I'm doing with my particular web service (an
electronic statement system) since I don't _want_ anyone able to talk to
my service without explicit consent. But because of the size of my
payloads and the processing time required to generate them (I'm
generating pdfs on the fly from XML) I don't want to hold the connection
open waiting for the response, so one of the parameters to the
requestStatement method is a callback URL and namespace. So, assuming
the request is valid, I respond immediately with that fact and a session
number, then when I finish generating the pdf, I post it to the callback
with the session number. So not only do I need to authenticate the
initial caller, I need to authenticate the callback as well.

Basically the security model looks like it's going to evolve into
something a lot like Kerberos, though because of deadline pressure I
can't get that complicated in the first release. Basically all I'm going
to do now is use a client-side certificate on the originating host to
secure the actual traffic and provide rudimentary caller authentication.
Then, I'll check to make sure the callback URL is in my authorized
caller list. If both these checks pass, then I'll proceed with
generating the statement.

The way I see it, whether or not you can talk to me _at all_ belongs at
the protocol level. But whether or not you're allowed to get what you
want to get from me belongs at the application level.

Fortunately for me, I don't really have to worry much about my requests
going from server to server to server... for now at least, there are
only two hosts that need to talk to each other (three if you count the
fact that I've separated authentication and generation onto separate

Like I said though, eventually, I see the security model evolving into a
kind of Kerberos over soap... the caller first talks to an
authentication host, which generates a ticket which the caller presents
to the actual service host, the service host talks to the authentication
host to make sure the ticket is valid, then proceeds with checking to
make sure the request is valid, then generates the pdf and sends it on
its merry way.

Anyway, I'm starting to ramble now...

|                                  \
|  Greg Symons                     /
|  Systems Analyst                 \
|  Research Federal Credit Union   /
|  (586) 264-8710 x1234            \

View raw message