jordan@CS.COLUMBIA.EDU (Jordan Hayes) (05/09/89)
I've been thinking about this for a while, and it seems to me that a Kerberized version of some new protocol (perhaps implemented in RPC rather than an SMTP-like interface, so that a dummy server could be built that would link directly into the client code to provide "local" newsreading without changing anything but a Makefile) at first sounds like the way to go, but administering a large list of who gets permission to do what is likely to be a major headache. For instance, you have class groups (cs160, for example) at Berkeley. There would be a list of who gets to read it, who gets to post to it, etc. It has to be kept on the kerberos server and needs to be updatable rather easily by a large number of people (TA's, professors, etc.). For the Kerberos folk: Does anyone have any experience with allowing an update facility to large numbers of "somewhat trustworthy" people on large numbers of access lists? For the news folk: Hasn't the time come for a library of routines to be written to do news-ish tasks, both client and (multiple) server? /jordan
pato@APOLLO.COM (05/10/89)
I've been thinking about this for a while, and it seems to me that a
Kerberized version of some new protocol (perhaps implemented in RPC
rather than an SMTP-like interface, so that a dummy server could be
built that would link directly into the client code to provide "local"
newsreading without changing anything but a Makefile) at first sounds
like the way to go, but administering a large list of who gets
permission to do what is likely to be a major headache.
For instance, you have class groups (cs160, for example) at Berkeley.
There would be a list of who gets to read it, who gets to post to it,
etc. It has to be kept on the kerberos server and needs to be
updatable rather easily by a large number of people (TA's, professors,
etc.).
For the Kerberos folk:
Does anyone have any experience with allowing an update facility to
large numbers of "somewhat trustworthy" people on large numbers of
access lists?
For the news folk:
Hasn't the time come for a library of routines to be written to do
news-ish tasks, both client and (multiple) server?
/jordan
The Apollo distributed user account management system provides this capability.
You can create any number of groups and associate different administrators with
each of those groups. Update access is available from any machine in the
network and the servers immediately propagate the information to all other
servers.
Apollo has shipped this product as part of base software in Domain/OS since
sr10 (July 1988) and has announced the product (under the name Passwd Etc) for
SunOS and Ultrix this week.
A general (dated) description of the system can be found in:
Pato, Joseph N.; et al. "A User Account Registration System for a Large
(Heterogeneous) UNIX Network", Proceedings of the Usenix Association Winter
Conference, 1988.
More recent information including new enhancements will be available from
Apollo sales offices.
Joe Pato UUCP: ...{attunix,uw-beaver,brunix}!apollo!pato
Apollo Computer Inc. NSFNET: pato@apollo.com
-------jhs%computer-lab.cambridge.ac.uk@NSFNET-RELAY.AC.UK (Jerome H Saltzer) (05/10/89)
> I've been thinking about this for a while, and it seems to me that a > Kerberized version of some new protocol (perhaps implemented in RPC > rather than an SMTP-like interface, so that a dummy server could be > built that would link directly into the client code to provide "local" > newsreading without changing anything but a Makefile) at first sounds > like the way to go, but administering a large list of who gets > permission to do what is likely to be a major headache. > For instance, you have class groups (cs160, for example) at Berkeley. > There would be a list of who gets to read it, who gets to post to it, > etc. It has to be kept on the kerberos server and needs to be > updatable rather easily by a large number of people (TA's, professors, > etc.). The mechanism you are looking for is an authorization system, probably in the form of a set of nested access control lists. But it probably should NOT be kept on the Kerberos server. When we worked out the design of Kerberos we debated whether or not to include an authorization system, and (after a fair amount of argument) decided not to. There are two fundamental reasons: 1. The dynamics of authorization cover a much greater range than those of authentication--there can be any number of access-control lists, they can be of arbitrary and unpredictable size, and they need to be be administered by a wide range of people. Compared with the small, slowly-changing, predictably-sized, and uniformly-administered database required for authentication, many of the design considerations were different, so it appeared more appropriate to separate the services. 2. There are many possible models for controlling authorization, and different network services may require (or prefer) different models. Rather than trying to choose the one best model, or try to implement a general system that caters to all possible models, it seemed better to leave the model up to the service. The way I would approach the business of controlling authorization for news would be to think through what control features are wanted, and then build up a news-specific mechanism, based on the assumption that it can rely on clients to present Kerberos-derived principal identifiers that are certifiably correct. > Does anyone have any experience with allowing an update facility to > large numbers of "somewhat trustworthy" people on large numbers of > access lists? Not exactly, but moderately close. There is a mail list, group list, and access list update mechanism in the Athena Service Management System (Moira). The lists have access control lists of their own and there is a Kerberos-mediated network protocol for remote update of lists. One could probably adapt this system to drive an access control system for the news system. Jerry Saltzer