[114] in Kerberos
Re: a different proposal for authori
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:30:08 1987
From Saltzer@ATHENA.MIT.EDU Tue Oct 14 14:52:06 1986
Date: Tue, 14 Oct 86 14:49:31 EDT
To: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)
Cc: kerberos, watchmakers, developers
Subject: Re: a different proposal for authorization, etc.
In-Reply-To: miller%erlang.DEC@decwrl.DEC.COM (Steve Miller)'s message of 14-Oct-1986 1151
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
Steve,
Thanks for the quick response. You have pinpointed the one issue
that worries me most about this approach, namely that any server that
uses the common authorization system must wait for a network
transaction; some servers may not be organized in a way that makes
that easy.
If we implement the list membership service via a network path to a
server running on the same machine, then desired services that are
organized with a single thread perhaps could accept a restriction:
their membership lists must be all handled locally by the first list
membership server asked. Since the first such server is actually on
the same machine the response is guaranteed to be quick. To enforce
such a restriction, the interface to and the protocol with to the
list membership server could both have a parameter that says "Don't
refer this request forward."
To reduce time further, it might be more appropriate to implement the
local list membership service as a library subroutine that works
directly with files stored in /site/authorizations/ and that invokes
a real network protocol only when those lists seem to refer to
outside, common lists.
Jerry
