Hi, On Sun, Sep 04, 2016 at 10:29:54PM -1000, Brent W. Baccala wrote:
> 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. I'm a bit confused here: my understanding was that you essentially wanted to implement a "single system instance" cluster. I would have thought that would imply only a single instance of most servers -- including auth -- rather than separate ones for each node?... Note that for the container solutions (lightweight virtualisation) I'm envisioning for the Hurd -- with things like sub-users -- we are likely to need some kind of auth delegation scheme or something like that; but I haven't spent too much thought on this. Not sure whether it would be relevant to your work in any way... On Mon, Sep 05, 2016 at 02:09:56PM +0200, Richard Braun wrote: > I'm not completely familiar with the inner workings of the auth > server but they look easy enough to imagine. Still, an opinion > from someone more familiar with it like Olaf would be great. I'm not really very familiar with the details of the auth protocol. The stuff I discussed extensively with Carl at some point (as a solution to the infamous "firmlink issue") was more about handling of the ID sets obtained through the auth mechanism -- I don't think it involved changes to the auth protocol itself... Not sure though. Maybe Carl remembers better than me? -antrik-
