Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!samsung!uunet!aplcomm!capd.jhuapl.edu!waltrip From: waltrip@capd.jhuapl.edu Newsgroups: comp.sys.next Subject: Re: Postscript Message-ID: <1991Apr29.132216.1@capd.jhuapl.edu> Date: 29 Apr 91 18:22:16 GMT References: <47755@ut-emx.uucp> <51753@nigel.ee.udel.edu> <47941@ut-emx.uucp> <1991Apr26.044349.5265@ni.umd.edu> Sender: news@aplcomm.JHUAPL.EDU Organization: CAPVAX, JHU/APL Lines: 50 In article <1991Apr26.044349.5265@ni.umd.edu>, louie@sayshell.umd.edu (Louis A. Mamakos) writes: > In article <47941@ut-emx.uucp> mic@ut-emx.uucp (Mic Kaczmarczik) writes: >> How about a DPS >> server that authenticates connections and file opens using Kerberos, >> and then uses your Kerberos credentials on your behalf to open files? In the X world, I believe this is done by a session manager process which is separate from the X server (which is separate from the window manager). The session manager, of course, can rely on Kerberos authentication for identifying the node and user. The security (that is, the user and node combos which will be permitted to access my display) are specified to the session manager by the user. I wonder if a similar architecture could be adopted with the NeXT? > > Wow, funny you should mention this. We will most likely be using > Kerberos authenticated AFS on our NeXTs anyway. I, for one, will be very interested in how you accomplish this. I would be very interested in NeXT accomplishing it FOR us all (2.2?). > > There is a need for a real authentication mechanism to be in place to > solve this and many other problems. And guess what, not all the > machines that have to do this are NeXT platforms. > > All we need do now is to figure out how to shove enough of NetInfo out > of the way to make this work. (How would you change your password on > the Kerberos authentication server with Preferences? How about with > `passwd'. Hmm.. And these are the obvious questions to ask.) Again, would be nice for NeXT to supply all this. This is another area where NeXT could benefit by adopting a standard OSF/1 OS (or by joining the ACE consortium). Much of the stuff they are using their scarce resources on doing are being done by the OSF or ACE people. I'd like to see NeXT concentrate on NeXTstep and forget about operating system development that is already contained in the OSF or ACE world. > > I also agree that a public/non-public switch on the window server is > not nearly fine-enough granularity. I hope the problem is solved by a > real authentication mechanism (see above) where I can specify specific > *users* and not just a list of IP addresses that I "trust." > > louie c.f.waltrip Internet: Opinions expressed are my own.