On Fri, Apr 08, 2005 at 07:13:54AM -0400, Greg Troxel wrote:
> Good points, but it makes me comment that it would be nice to somehow
> have a server process or computer be able to operate in multiple
> realms.

I do not think it is possible. A Coda server process is running
in a context of a certain realm. My guess is that it is unaware of the whole
concept of realms. So it listens for requests and knows exactly what to do
with them without further multiplexing.

On the other side, you can easily run server processes for different realms
on the same hardware simultaneously (of course unless you use hardcoded
paths to configfiles, my servers don't :)
Of course, you will have to arrange for different ip-numbers for those
servers to listen on - and that will be the multiplexing point.

> realm foo.com   with servers at a.foo.com, b.foo.com, a.bar.com
> realm bar.com with servers at a.bar.com, b.bar.com, a.foo.com

Instead:
realm foo.com   with servers at a.foo.com, b.foo.com, c.bar.com
realm bar.com   with servers at a.bar.com, b.bar.com, c.foo.com

where c.bar.com and a.bar.com would share hardware, as well as
c.foo.com and a.foo.com.

On the other side, why would you use two distinct realms in the first hand,
if you administer all of these machines anyway?
If you don't administer the machines, you do not want to put your server
there - it is a very intimate relation, including the presence of the
realm main secret on the disk.

> In this case the a.foo.com server functions for foo and bar, but those
> uses are logically independent, different authentication, etc.

You _can_ use different authentication databases inside one realm.
Well, to do it right, some changes to the server internals are still needed
but it should be done anyway - IM very HO.

The modular clog provides the framework for arbitrary sets of authentication
databases inside the same realm (say, multiple independent Kerberos realms).
It has the advantage that accounts from different "authentication domains"
can be naturally present in acls on the same objects - which is impossible
between realms (some more deep changes would have to be done otherwise)

> I just wanted to throw out this concept as we slowly moved towards a
> useful realization of the security/authentication/encryption model.

A change in the servers' user database format and semantics is necessary,
but it seems to have a low priority, as most realms do fine with one
authentication database (though I am routinely using two per realm)

[see:
 xyz/adm-pass_at_provider.com
-^^^----------------------------- account name in a context of an auth db
-----^^^------------------------- the corresponding db identifier in that realm
---------^^^^-------------------- identifier of the protocol which the client
                                  is going to use to talk to that db
--------------^^^^^^^^^^^^------- the realm

compare to:
 abc/customer-krb5_at_provider.com

 abc/customer-krb5 and abc/customer-unixhash would be the same identity,
 though the authentication server may refuse a method other than "krb5"

 "xyz/adm" is of course _not_ the same as "xyz/customer",
which current server internals do not distinguish - but it can/should be fixed,
with realively low pain
]

Regards,
--
Ivan