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 Thu, 06 Jun 2002 19:13:04 GMT
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