From: Jeff Bone (jbone@jump.net)
Date: Mon Oct 02 2000 - 12:40:19 PDT
> What about this idea: signed streams. The stream isn't encrypted, it just does
> a handshake when it connects to the proxy. If there is a service that does
> nothing but sign certificates for code that needs to bust through the firewall,
> then to stay viable it depends on only signing for reputable parties. So the
> sysadmin says "I'll allow all traffic signed by Joe because I trust Joe to do
> hacker detection conscientiously." For sysadmins this might fix the problem of
> all the non-browser data passing through 8080.
>
This is very close to a great idea. ;-) The problem: inbound connections to a
particular user / service pair where the user isn't the initiator. Example: a p2p
buddy list scenario where an external user is attempting to add an internal user;
the external BL tries to connect directly in order to submit a request to be
notified about the internal user's presence updates, etc. The inbound messages /
streams / whatever cannot be signed by the trusted internal party a priori.
The right thing to do is to simply replace the notion of ports with URLs on the
firewall; imagine a service proxy that allows an internal user to register to
receive a variety of SOAP requests at locations in a symbolic URL namespace residing
at the firewall. In other words, say the firewall is
The user's various services "adopts" subtrees on the users behalf underneath that
such as
jbone@foo.com">http://soapserver.foo.com/jbone@foo.com (a general soap dispatcher)
jbone@foo.com/buddies/subscribe">http://soapserver.foo.com/jbone@foo.com/buddies/subscribe
jbone@foo.com/workspace">http://soapserver.foo.com/jbone@foo.com/workspace
jbone@foo.com/workspace/index">http://soapserver.foo.com/jbone@foo.com/workspace/index
jbone@foo.com/music/index">http://soapserver.foo.com/jbone@foo.com/music/index
http://soapserver.foo.com/entrepreneur-support-group/bitching
etc. Each of these URLs identifies a particular endpoint for a particular kind of
traffic. (The whole service proxy notion should support some sort of reflection;
you should be able to grope through and find semantically meaningful descriptions of
services, interfaces, etc.) The firewall (and admin) are happy because the internal
user can be authenticated and authorized, and the user is happy because they can
then essentially utilize any services which can make user of the piece this
namespace. No need to sign the stream on the originating end, unless that's an
application requirement.
jb
This archive was generated by hypermail 2b29 : Mon Oct 02 2000 - 12:57:12 PDT