I took the same approach. In my case it was to implement an authentication interface.
The authentication is really simple, nothing fancy at all. I have 2 providers SecuredProvider and StandardProvider. SecuredProvider checks for a userid element in the SOAP header. If it's not present or can't be verified the request is rejected and never makes it to the service method. StandardProvider simply forwards the request as normal without any checks. In my deployment descriptor I simply specify which provider to use. Any service can be switched from secured to unsecured simply by changing the deployment descriptor. I would be glad to provide code samples if anyone is interested. Mike -- --------------------------- May The Source Be With You! http://www.mikesbox.com On Wed, 2002-06-05 at 13:11, Tiago Fernandes Thomaz wrote: > That was exactly what I did. I let rpcrouter servlet as the routing > mechanism in order to driect any soap request to my (only) soap service. > Only, because that service (according to my strategy) acts as a xml parser. > In fact this service is responsible to retrieve all xml embedded request > info and subsequently direct the request to specified path. > > Tiago Fernandes Thomaz > > > -----Original Message----- > From: Greg Symons [mailto:[EMAIL PROTECTED]] > Sent: quarta-feira, 5 de Junho de 2002 16:53 > To: [EMAIL PROTECTED] > Subject: RE: SOAP & servlet model parallels > > > 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. 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. > > __________________________________ > | \ > | Greg Symons / > | Systems Analyst \ > | Research Federal Credit Union / > | (586) 264-8710 x1234 \ > |__________________________________/ > > -----Original Message----- > From: Erich Izdepski [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 05, 2002 9:46 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: SOAP & servlet model parallels > > > You can extend the soap rpcrouter and direct all calls to your new > class, providing a point to put in whatever other processing (your > authentication, needs, perhaps) you might want. > > Erich Izdepski > Senior Software Engineer > Cysive, Inc. > > > -----Original Message----- > From: Steven J. Owens [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 05, 2002 4:25 AM > To: [EMAIL PROTECTED] > Subject: SOAP & servlet model parallels > > > Hi, > > I'm quite familiar with the servlet world and I'm getting into > SOAP. I have to say, the general idea of SOAP seems quite natural and > right to me, and I'm happy to see it taking off the way it has. I'm > also quite impressed by Apache SOAP, so far. > > In considering how to structure applications that are heavily > SOAP-oriented, I'm starting to see a lot of parallels between the two > models. I look at solving a problem and I feel like, "well, in the > servlet world I'd solve that with foo... so where's the equivalent in > the Apache SOAP world?" > > In the past, I've been involved with projects where a lot of the > fundamental structure of the application was built by somebody who > didn't really know the servlet model, and hence reinvented a lot of it > in the process. Sometimes this lead to advantages, but it also added > work, added cognitive overhead in learning and working with the code, > made it less standard, and made it harder to plug into new tools and > innovations as they came along. I hope somebody here can steer me in > the right direction, to avoid that sort of mistake. > > Some specific examples... > > A typical/straightforward SOAP application boils down to SOAP > calls, encoding types, and SOAP handlers. Assume, for the sake of > argument, that you're using the default encoding types. You define the > types of messages and you set up the SOAP server's configuration to > field each message type off to an appropriate handler. > > So far, so good. Now what my actual application needs, beyond the > SOAP communication layer, is a configurable rules scheme where a request > is processed according to a configuration file, and an appropriate class > gets instantiated and invoked to handle the request...hey waitaminnit, > that looks an awful lot like the whole Apache SOAP setup. > > So why don't I just use that to do it? That way I can use Apache > SOAP not only to define the pipe/wire, but also to define the larger > structure of the application itsef, and I'm using more standard code, > implementing less on my own, and making the system easier for somebody > else who's familiar with SOAP to manage. > > Only problem is, I need to configure some sort of security scheme, > so each request gets checked for authentication before being fielded off > to a request-specific handler. In the servlet world, as of spec 2.3, > that's done with filters - providing this sort of cross-cutting > processing is the whole reason for filters. Is there a filter > equivalent in Apache SOAP? > > In the pre 2.3 servlet world it was done using a single front-end > servlet using a RequestDispatcher to field requests off to other > servlets. This avoided the overhead of a browser redirect, and provided > convenient mechanisms for adding state to the request at each step of > the process. Is there an equivalent to the RequestDispatcher in the > Apache SOAP world? Can I have messages get bounced around to internal > SOAP handlers/servers without paying the overhead of serializing out to > XML and reparsing repeatedly? > > As part of that front-send servlet strategy, some sort of security > realm configuration would be used to keep the other servlets from being > publically accessible. Is there any sort of server-configurable > security scheme for doing something like that in Apache SOAP? Would I > just the Jakarta security realm stuff to secure SOAP pieces? > > Come to think of it, when I install the Apache SOAP server, it > comes with an administration interface. Is there anything in SOAP > itself to secure that, or do I just need to use the Tomcat security > realm stuff to secure it? > > I hasten to point out that I can think of a variety of ways to code > a system to do all of this; a singleton-ish security manager class that > gets invoked by all of the handlers I write, for example, and an > similarly just using a single handler for all messages, that single > handler walking an XML file and using reflection to instantiate an > appropriate class and invoke it. I'm interested in finding "the Apache > SOAP" way (or even just "the SOAP way") to do it, or at least in > definitively figuring out that there is no "Right Way" before I go off > and invent a lot of code that has to be understood and maintained. > > Steven J. Owens > [EMAIL PROTECTED] > > "I'm going to make broad, sweeping generalizations and strong, > declarative statements, because otherwise I'll be here all night and > this document will be four times longer and much less fun to read. Take > it all with a grain of salt." - Me
