>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
[EMAIL PROTECTED]
191 Grand Street, Brooklyn NY 11211
718.599.4893
______________________________________
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
