home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 35 Internet / 35-Internet.zip / srev13h.zip / USERS.DOC < prev    next >
Text File  |  2000-04-14  |  4KB  |  105 lines
  1. 15 June 1999.  SRE-http username/password file                    
  2.  
  3. I.      Introduction
  4. I.a     The  usernames and passwords file (USERS.IN)  
  5. I.b        Examples  
  6. I.c        Advanced options: Dynamic passwords 
  7.  
  8.                 ----------------------------------
  9.  
  10.  
  11. I. Introduction
  12.  
  13. The SRE-http USERS.IN file is used to register users. Each entry in
  14. USERS.IN contains a username, a password, and an optional list of
  15. client privileges.
  16.  
  17.                 ----------------------------------
  18.  
  19. I.a) The  usernames and passwords file (USERS.IN)  
  20.  
  21. Each entry in the the USER_FILE (with default name USERS.IN) contains an 
  22. optional host nickname, a username, password, and privilege information. It is 
  23. used in two cases: 
  24.  
  25.   1. When logon is required of a client.
  26.  
  27.   2. When information on privileges is needed.
  28.  
  29. The structure of the USER_FILE is:
  30.     HOST_NICKNAME// NAME PASSWORD PRIV1 PRIV2 ?PRIV_SECRET ...
  31. where
  32.    HOST_NICKNAME// is the (optional) host to which this entry applies
  33.   NAME is the case insensitive username
  34.    PASSWORD is the password, which might be case sensitive 
  35.    PRIV1 ... is an optional list of privileges. 
  36.  
  37.  
  38. Note: if a HOST_NICKNAME// is NOT specified, then an entry is valid
  39. for ALL hosts. In other words, when processing USERS.IN "superceding" and
  40. "strict-superceding" hosts are treated as if they were "non-superceding" 
  41. hosts.
  42.  
  43.                 ----------------------------------
  44.  
  45. I.b) Examples  
  46.  
  47.   DANIEL A11S34WZ SUPERUSER
  48.   MIKE  IOWAMAN    CONSULTANT
  49.   JILL  GOBOTS     INHOUSE
  50.   JOHN  KIOWA      INHOUSE  VENUS  ?JUP1241
  51.   FLOWERS//  CHARLES BROWN PRICELIST
  52.  ANONYMOUS *  PUBLIC
  53.  
  54. In the above example:
  55.  
  56.    @ DANIEL is given SUPERUSER privileges. This could be useful if DANIEL 
  57.      needs to reset the server from an out-of-town site ... but it could be 
  58.      dangerous (so use an obscure password)! 
  59.  
  60.    @ JILL and JOHN are IN-HOUSE users. Thus, if CHECKLOG=INHOUSE, then DANIEL, 
  61.      JILL, and JOHN are allowed in, but MIKE is NOT allowed in (MIKE is allowed 
  62.      in, given correct entry of his username and password, if CHECKLOG does not 
  63.      equal INHOUSE). 
  64.  
  65.    @ JOHN is given VENUS privileges (as well as INHOUSE privileges). He is also 
  66.      given a JUP1241 SECRET PRIVILEGE (which could be used as a second level 
  67.      "password" in a security conscious addon -- see DYNPWD.DOC for details). 
  68.  
  69.    @ CHARLES has logon rights on the host with HOST NICKNAME of FLOWERS (but not 
  70.      on any other host). 
  71.  
  72.    @ ANONYMOUS is given PUBLIC privileges, and can use any password (and
  73.      is valid across all hosts).
  74.  
  75.     Note that * means "anything matches", and can be used in either the password 
  76.     or username fields. 
  77.  
  78. Note that all the passwords, in the above examples, are in upper case.
  79. For basic authentication, this does not matter -- the client's authentication
  80. information is converted to upper case. However, for digest authentication
  81. case may matter -- SRE-http checks some, but not all, case permutations of the
  82. password (entered by the user).
  83.  
  84.  
  85.                 ----------------------------------
  86.  
  87. I.c) Advanced options: Dynamic passwords 
  88.  
  89. One of the problems of BASIC AUTHENTICATION (the method supported by most 
  90. http/1.0 clients) is that passwords can be easily decoded by a 
  91. "man-in-the-middle". Digest authentication, supported by SRE-http and http/1.1 
  92. browsers, largely solves this problem (by encoding passwords using advanced 
  93. cryptographic techniques). However, until the time that everyone uses http/1.1 
  94. browsers, there is a need for some intermediate technique. 
  95.  
  96. SRE-http provides such a mechanism based on the client and the SRE-http server 
  97. sharing an encoding mechanism. This requires complementary procedures: one that 
  98. SRE-http can use to decode a password, and the other for a clent to encode one 
  99. (i,e.; a program she can run before filling in a password field on the browsers 
  100. authenticaton screen). 
  101.  
  102. For details on this capability, see DYNPWDS.DOC.
  103.  
  104.  
  105.