Cross domain authentication
D1120604384
Asteve (81.96.207.141)
#Cross domain authentication has been implemented in two different
#forms recently (Jul 2005), however there is still discussion about
#the "best" solution.
#
#IMPLEMENTATION 2
#
#Central authentication server
#[http://groups-beta.google.com/group/comp.os.plan9/msg/4625ee53672ef106?dmode=source&hl=en]
#
#IMPLEMENTATION 1
#
#Distributed authentication
#[http://groups-beta.google.com/group/comp.os.plan9/msg/3c379056e750c514?dmode=source&hl=en]
#
#A EARLIER, SIMILAR PROPOSAL
#
#(Taken from a post by David Presotto to the 9grid list:
#[http://nwn.definitive.org/pipermail/9grid/2004-September/000269.html])
#
#In the current scheme, when a user authenticates, he/she gets a list
#of domains that the server will accept and picks one to use (i.e.
#one he has a key for). That should provide the second part of the
#name, i.e., if I'm presotto authenticating via the domain
#bignose.com then I should be presotto@bignose.com. Tacking on the
#@bignose.com is currently missing.
#
#That of course leaves the server to map the domain bignose.com to an
#auth server that it trusts (i.e. has a key for and trusts others to
#authenticate via). Currently that's done via the lib/ndb entry
#
#! 	authdom=bignose.com auth=1.2.3.4
#
#So we have a way to trust other authentication domains but not yet a
#way to tag the resulting name. However, that's like 1 line of code
#in factotum.
#
#However, this requires that there be a shared key twixt each server
#and each domain that it trusts. I'll leave it up to you if that's
#too much.
#
#If the server is a cpu server, then the caller can export its
#factotum to its process on that cpu server so that it can
#authenticate further. Is this a good idea? Would we be letting too
#much access to the factotum? Might we want the user to start a
#second less capable factotum for 9net access?
#
#The client coming into the cpu server will need at least readonly
#access to binaries and to enough directory structure to set up a
#name space on that machine. I already had to make that work for the
#deep lens survey stuff. I made ken's group 'noworld' access work for
#that. If we put each 9net user in the 'noworld' group, then we can
#point him to a file server and he can only get at files that are
#accessible by his uid or by the 'noworld' group. You could even give
#him some write access if you wanted to. It keeps such users from
#accessing anything that was accidentally made world readable or
#writable. It does mean that you have to change the file server so
#that anyone coming in as a@b is just treated as a 'noworld' group
#user.
#
#My 2 cents.
#