Extensibility & Security

I believe extensibility is not orthogonal to security.  Hence, the design
goal of extensibility will need to be reduced or eliminated in order to make
SOAP securable (at least for a firewall proxy).  Less extensibility may also
help prevent vendor hijacking of standards as recently demonstrated with
Kerberos.

There are also issues here with interoperability (and competition) with
existing RPCs, ORBs, and their respective security models.  Are we building
a never ending list of middleware that requires security mappings here?

Another issue that has a security angle is session management.  Would SOAP
be synchronous like most RPCs?  In which case, a possbile subversive goal of
would be that of session management (which allows for session security and
allows for license monitoring -- something these vendors and most
governments crave).

Encryption and tunneling are fine concepts, but as pointed out previously,
there is much work on the authentication and authorization pieces.
Certificates go a long way to addressing this, but it has it's own issues
(like it requires physical storage, issuance and tracking, and revocation
lists).

For SOAP as an RPC, I believe Java programmers are familiar with the need to
communicate an object's methods to other objects (introspection or
something?).  Unless programmers on both ends know what methods are offered
by the distant end, how can they implement RPCs?  Do you have a directory
server that keeps this with the URI or what?  If you require this level of
communication between programmers, what's the point of a standard like SOAP?
You could just as easily use DCOM or CORBA/IIOP -- what does SOAP give me
that I don't already have (besides headaches)?  

Toby Meehan, WAN Administrator
Catalyst International, Inc.

Received on Thursday, 18 May 2000 15:35:28 UTC