home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / protocol / kerberos / 680 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  2.9 KB
  1. Path: sparky!uunet!olivea!spool.mu.edu!agate!stanford.edu!ATHENA.MIT.EDU!tytso
  2. From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
  3. Newsgroups: comp.protocols.kerberos
  4. Subject: Re: Existing authentication mechanisms have a deficiency
  5. Message-ID: <9209090426.AA25857@tsx-11.MIT.EDU>
  6. Date: 9 Sep 92 04:26:09 GMT
  7. References: <9209082303.AA10434@ocfmail.ocf.llnl.gov>
  8. Sender: news@shelby.stanford.edu (USENET News System)
  9. Organization: Internet-USENET Gateway at Stanford University
  10. Lines: 50
  11.  
  12.  
  13.    Date: Tue, 8 Sep 92 16:03:34 PDT
  14.    From: nessett@ocfmail.ocf.llnl.gov (Danny Nessett)
  15.  
  16.    It seems to me, after the discussion about su, ksu, etc., that
  17.    something is missing from existing distributed authentication
  18.    mechanisms.....
  19.  
  20.    If an organization wants to keep its authentication data in exactly
  21.    one place, existing authentication mechanisms are insufficient. 
  22.  
  23. Yup.... what's missing is "an authorization mechanism".  Both Kerberos
  24. and SPX purport to offer an "authentication", and completely punt on the
  25. "authorization" issue, leaving that as an exercise for the application
  26. writer to deal with.
  27.  
  28. While this may seem to be an amazing cop out, since every nearly every
  29. application which uses the authentication services provided by Kerberos
  30. or SPX will require some sort of authorization policy, even if it is as
  31. simple as checking an ACL, file, there is a good reason for this design
  32. choice.  And the reason is this:  
  33.  
  34.     While authentication systems are relatively well-understood at
  35.     this point, authorization policies are not.  
  36.  
  37. Specifically, there is no good, general model which shows what sort of
  38. functionality an system would need in order to provide a completely
  39. general authorization policy which would work for all possible
  40. applications.  There have been attempts to do so --- ECMA has issued one
  41. or two technical reports which try to do so --- but they tend to be
  42. fairly confusing, and it is not clear at least to me whether they
  43. generate more light than heat.  So it seems fairly clear to me that a
  44. workable authorization framework is at least partially still an area for
  45. research.  
  46.  
  47. What we use at MIT Project Athena is a system called "Moira" to handle
  48. our authorization policies.  Specifically, it is a database system which
  49. automtically distributes configuration files to most of the Project
  50. Athena servers every night.  This allows most of the authorizatrion
  51. information to bee kept in exactly one place, as your requirement
  52. specifies.  Since connections to Moira require a Kerberos-authenticated
  53. connection, reasonable access list control can be placed on the Moira
  54. database, and it is even possible to figure out who made what
  55. modifications to a particular database entry.
  56.  
  57. Moira is big and hard to set up (it runs on top of Ingres), so it may
  58. not be appropriate for all sites.  But it is one solution which keeps a
  59. large part of the authorization information in one centralized place.
  60.  
  61.                             - Ted
  62.