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.