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: [EMAIL PROTECTED] > 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:[EMAIL PROTECTED]] > > Sent: Thursday, June 06, 2002 12:33 PM > > To: [EMAIL PROTECTED] > > 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 > > [EMAIL PROTECTED] > > www.codenoevil.com > > > > Code Made Fresh DailyT > > ----- Original Message ----- > > From: "Greg Symons" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > 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 \ > > |__________________________________/ > > > > > > > > >
