xml-soap-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Symons" <gsym...@researchfed.com>
Subject RE: SOAP & servlet model parallels
Date Fri, 07 Jun 2002 16:24:17 GMT
Just to add some more thoughts on this I suppose the authentication
tokens really belong in the header of the envelope rather than in the
actual method call.

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

> -----Original Message-----
> From: Greg Symons 
> Sent: Thursday, June 06, 2002 3:13 PM
> To: soap-user@xml.apache.org
> Subject: RE: SOAP & servlet model parallels
> 
> 
> That's basically what I was saying, but in a far more 
> succinct, to the point way:) Basically, I see the provider 
> stepping in and taking the tokens and validating them against 
> the authentication machine before passing the request to the 
> RPCRouter. That way you can keep your security model out of 
> your actual business model.
> 
>  __________________________________
> |                                  \
> |  Greg Symons                     /
> |  Systems Analyst                 \
> |  Research Federal Credit Union   /
> |  (586) 264-8710 x1234            \
> |__________________________________/
> 
> > -----Original Message-----
> > From: David B. Bitton [mailto:david@codenoevil.com]
> > Sent: Thursday, June 06, 2002 12:33 PM
> > To: soap-user@xml.apache.org
> > Subject: Re: SOAP & servlet model parallels
> > 
> > 
> > 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 envelope.
> > 
> > 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
> > david@codenoevil.com
> > www.codenoevil.com
> > 
> > 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
> > systems:)
> > 
> > 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            \
> > |__________________________________/
> > 
> > 
> > 
> > 
> 

Mime
View raw message