Ok.
So the client authenticates on the external server. The client then
clicks on a link to go to the restricted section on our webserver in
such a way that they will be pre-authenticated on our server. When
the user clicks that link, a script on their end is executed to open a
socket to our end so the user's data can be passed to us. I assume
that once all of that has transpired and the external server has
recieved the go ahead from us, the external server then redirects
the user to our server? And would the external server have to pass
something with the URL so we can associate that particular client
with the data that was just passed? If not, how do we make that
association?
Chris,
I don't know how helpful I will end up being to your project. I offer you my help only as someone who is in the process of exploring something similar myself -- so what I'm dealing with here is a public brainstorm, and certainly nothing near a finished solution.
I wish I were at the pseudo code stage, as I would love to be that far along, and be able to help you out.
However, I'll try to clarify the mechanics of my thinking, in case anyone on this list cares to point out any obvious flaws in logic (and therefore can help us both out).
The basic idea is to get the servers to agree on allowing a user to access them both, for a limited time, and ONLY if they both agree on allowing the user in. If we can get the servers to shake hands on letting user X be authenticated, then, when user X requests a resource, the servers can check their recent agreements lists for whether user X should be allowed that resource. By having the servers talk directly to each other (and not via the user's browser) on this "pre-verification" stage, it would seem to me that no third party would have access to the mechanism of the transaction, and, since the communications are encrypted with PGP with keys that physically reside on those two servers, even if this hidden communications stream were snooped, it would be awfully difficult to replicate the mechanism of the authorization.
On top of this basic architecture, we then lay a few added complications: time-sensitivity (that the authorization expires strictly after a very brief time unless used immediately), and continued verification that all communication between parties is actually coming from the same IP addresses from which they originated.
Here's my poorly written schematic:
Server A Server B
User logs in and is authenticated,
preferably over SSL, and using
some kind of time stamp and IP
address verification.
Server A gives a key to the user
Server A also encrypts the key,
using Server B's public PGP key
(just 'cause it's called public
doesn't mean it has to actually
be public).
Server A opens a socket to server
B and sends this key to server B
(not sure if this can be done
over SSL. thinking that perhaps it
can be done with an SSH session?).
Also, all of these server side
sockets should be made to verify
the IP address of the server opening
the socket. There should also be a
relatively strict timeout on all
these transactions, such that an OK
or auth key will expire if not used
or validated within five minutes.
Server B receives key,
decrypts it with it's
private key, and returns an
"OK" response to Server A.
This OK would be encrypted
with server A's public key,
and would be mathematically
related to, or contain the
user's request for authen-
tication, so that when
server A receives the OK,
it knows to which user it pertains.
Server B makes a note (in
a database or whatever)
of the OK. This note would
also contain the users
session key, so it knows
which user should event-
ually be given access.
Server A redirects user to Server B,
sending the original authorization
key along with the user (in a
cookie, or session ID)
Server B sees user with
auth key, checks to see if
there is an OK registered
in it's database corres-
ponding to that auth key.
Here we can also add time-
sensitive verification, as
well as a check to see
whether the original auth-
orized user's request is
still coming from the same
IP (subject to proxy server
restrictions if user comes
from large ISP). I.E.
if( auth OK && record of
auth && same IP && within
last 10 minutes) then
give user a page which
verifies that the user
has the key, that server
B has a key, that it
corresponds to a recent
record of authorization
in it's database, that's
it's coming from the
same IP as the request for
auth came from from
server A, and then gives
the user the data.
--
______________________________________
Kristofer Widholm
Web Pharmacy
webpharmacy@brokenhill.net
191 Grand Street, Brooklyn NY 11211
718.599.4893
______________________________________