Aloha -

For those of you who have followed my netmsg threads, you may remember that
there were two major issues when I first got it running.  One was
libpager's lack of multi-client support, which has been discussed at
length, and the other was authentication, which we haven't discussed at all.

Here's my proposal for dealing with the authentication issue.

There should be an extra send right passed from the auth server, to the
client, that the client then passes along to the server in its
authentication request, and that the server then passes on to the auth
server in its auth_server_authenticate messsage.  This is distinct from the
auth_object.  Unlike the auth_object, this right conveys no credentials and
is used primarily to identify the auth server.  Let's call it the
auth_identifier.

In the present scheme, you can see that the auth_identifier gets passed
around in a big circle.  When the auth server gets the
auth_server_authenticate message from the server, it sees that it's gotten
its own auth_identifier back, and things proceed as they do now.

The more interesting case is when the auth_identifier differs.  That
happens when we're dealing with two different auth servers on different
hosts.

First, the auth_identifier allows the auth server to detect this case.

Next, it provides a means for the two auth servers to complete the
rendezvous.  The server's auth server can pass the rendezvous right to the
client's auth server using the auth_identifier.

There's no way for the server's auth server to fool the client's auth
server into thinking that this is a normal server authentication request,
because the only communication between the two is via the auth_identifier.
The client's auth server can clearly distinguish messages coming in over
this port from auth_server_authenticate messages, which would come directly
from a server over a different port.

Finally, the auth servers can use the auth_identifier to speak any kind of
inter-auth-server protocol that they wish.  At the moment, the exact
details of that protocol are beyond the scope of this proposal.  I
envision, perhaps, a public key exchange.  Something that would let
mutually cooperating auth servers decide how to map UIDs/GIDs from one auth
domain to another.  I haven't thought through the details, but I think this
proposal is flexible enough to handle just about anything we'd want to do.

Comments?

    agape
    brent

Reply via email to