Erich Izdepski [mailto:[EMAIL PROTECTED]] wrote:
> 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.
This sounds like a good way to begin a custom implementation, but
I wanted to make sure I wasn't stepping on some existing mechanism in
either SOAP or Apache SOAP that's intended to do this.
Do you know, is there any documentation about the overall
structure of the Apache SOAP code, beyond the API docs? Something
like a walkthrough of how the server gets deployed, what classes get
invoked when a message comes in, etc. I guess this would be more on
the order of an Apache SOAP developer's introductory tutorial.
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.
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.
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.
My second thought was that, since SOAP is typically moved around
in MIMEs (I'm not sure if this is universally true or if it's just
true in the most common case, of SOAP being carried via http or smtp),
just use standardish email mime-based digital signature and encryption
to provide per-message. That way you at least have the security being
carried in the message, not in the protocol.
Just to clarify this approach: my copy of O'Reilly's _Programming
Internet Email_ says there are two widely-used approaches, which
differ only in small details. Essentially MIMEs can be multipart, and
any given part can contain an entire other MIME, which can also be
multipart. Both widely-used approaches take a given MIME and
encapsulate it in another two-part MIME, where one part is a generated
digital signature. Encryption is handled the same way; encrypt the
existing data, create a new two-part MIME with the encrypted data as
one part and necessary management info as another part. Both
approaches use this strategy. Both approaches sign first, then
encrypt.
My third thought was that although either of those provide for
the basic security need, they kind of undercut the fundamental
benefits of SOAP. Such security approaches prevent a SOAP message
from being effectively relayed from server to server. Or rather, to
relay from SOAP server to SOAP server, you have to set up
corresponding security tunnels & authentication certificates between
each server. There's no way to take advantage of the intelligence of
the SOAP transport layer, since all of the information you have on the
message is locked up tight inthe encryption.
It'd seem to me, what's needed is a scheme where you have SOAP
message with some internal pieces of it encrypted and/or signed, so
that you can do some degree of parsing and processing of the overall
message, maybe adding further signatures as headers in the process.
I've got to go back and re-read the SOAP encryption and signature
specs (I have to admit, the first time around they were at the bottom
of a fairly tall stack of reading). Left to my own devices, I suspect
I'd just reinvent the standard Email approach, using a hierarchy of
XML elements instead of MIME, and of CDATA encoding instead of base64.
Maybe I'd use SOAP attachments to avoid CDATA encoding lots of stuff.
But the major change would be allowing for chunks of a message to
be encrypted or signed, and for SOAP handlers along the way to add
their own signatures. I'd like come up with some scheme to avoid
having each SOAP server that does some processing have to encapsulate
the whole thing. Or if not that, come up with a consistent approach
for having the encapsulations be able to be collapsed at the
destination.
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
