Specifying usernames/passwords, and INHOUSE addresses, in SREhttp/2

I. Introduction

Alternatively, you can specify your own procedure for looking up usernames and passwords.

I.a) The usernames and passwords files (USERS.CFG)

The structure of a username entry is:
    NAME PASSWORD PRIV1 PRIV2 ?PRIV_SECRET ...
where:
    NAME is the case insensitive username
    PASSWORD is the password, which might be case sensitive
    PRIV1 ... is an optional list of case-insensitive client privileges.

Or, to enter an IP address...
    INHOUSEIPS numeric_ip_address PRIV1 PRIV2 ...
where:
    INHOUSEIPSis the case insensitive word INHOUSEIPS
    numeric_ip_address is a dotted numeric IP address (not a domain name).
    PRIV1 ... is an optional list of case-insensitive client privileges.

USERS.CFG, like other SREhttp/2 CFG files, can be host-specific. As described in HOSTDATA.HTM, SREhttp/2 will use host-specific usernames first, and then (depending on whether the host is "superceding") check for "default" values.

I.b) Examples

  DANIEL A11S34WZ SUPERUSER
  MIKE  IOWAMAN    CONSULTANT
  JILL  GOBOTS     INHOUSE
  JOHN  KIOWA      INHOUSE  VENUS  ?MANAGER:JUP1241
  ANONYMOUS *  PUBLIC 
  INHOUSEips  201.233.61.* 

In the above examples:

• DANIEL is given SUPERUSER privileges. This could be useful if DANIEL needs to reset the server from an out-of-town site ... but it could be dangerous (so use an obscure password)!
• JILL and JOHN are INHOUSE users.
• JOHN is given VENUS privileges (as well as INHOUSE privileges). He is also given a MANAGER:JUP1241 "secret privilege" (which could be used as a second level "encrypted password" by the MANAGER addon -- see DYNPWD.TXT for details).
• ANONYMOUS is given PUBLIC privileges, and can use any password (andis valid across all hosts).
• * means anything matches, and can be used in either the password or username fields.
• All clients with an IP address that matches 201.233.61.* are given the INHOUSE privilege.

I.c) Client Privileges

There are several ways of granting client privileges to a client:

1. Via the SUPERUSERS SREhttp/2 parameter.
2. Using an INHOUSEIPS entry (in USERS.CFG).
3. Using a username and password entry (in USERS.CFG).

I.d) Notes

II.a) Advanced options: Dynamic passwords

One of the problems of BASIC AUTHENTICATION (the method supported by most http/1.0 clients) is that passwords can be easily decoded by a "man-in-the-middle". Digest authentication, supported by SREhttp/2 and http/1.1 browsers, largely solves this problem (by encoding passwords using advanced cryptographic techniques). However, until the time that everyone uses http/1.1 browsers, there is a need for some intermediate technique.

SREhttp/2 provides such a mechanism based on the client and the SREhttp/2 server sharing an encoding mechanism. This requires complementary procedures: one that SREhttp/2 can use to decode a password, and the other for a clent to encode one (i,e.; a program she can run before filling in a password field on the browsers authenticaton screen).

For details on this capability, see DYNPWDS.TXT.

II.b) Advanced options: Custom username procedures

Suppose you want to use a custom means of looking up usernames and verifying whether a client is to be granted access to a resource. SREhttp/2 allows you to do this via its CUSTOM_USERNAME procedure.

For example, you might want to use a database manager program to check & store usename/password/privilege information (instead of SREhttp/2's USERS.CFG), and to determine whether access is to be granted or not (perhaps using information other then the "required privileges").

To do this, set the CUSTOM_USERNAME parameter in PRELOADS.CFG.

SREhttp/2 will pass several arguments to a CUSTOM_USERNAME procedure:
    auth_header,client_address,servername,host_nickname,request,requires
where:

• Auth_Header: The value of the authorization request header
• Client_address: the client's numeric IP address
• Servername: the servername to whom this request is directed (say, as specified in a HOST: header)
• Host_Nickname: host_nickname assigned to the servername (possibly DEFAULT).
• Request: the request string (i.e.'GET /foo.bar http/1.0'
• Requires: the required privileges, as drawn from ATTRIBS.CFG

The status must be an X,0, or 1:

• X : Excluded -- let the regular SREhttp/2 username and client privilege lookup procedures do the job instead.
  PRIVILEGE_LIST should be empty (SREhttp/2 ignores it).
• 1 : Logon successful.
  PRIVILEGE_LIST is optional. It can include "client privileges" that may be used by SREhttp/2 addons, EXEC procedures, etc.
• 0 : Logon unsuccessful.
  If PRIVILEGE_LIST is empty, SREhttp/2 will send an authorization response.
  Otherwise, PRIVILEGE_LIST must contain the response code from a response sent by the CUSTOM_USERNAME procedure; typically, this is the value returned by SRE_COMMAND or SRE_AUTH_RESPONSE.

Notes:

• Your CUSTOM_USERNAME procedure can use any of the SRE2003 procedures. Of particular interest are:

           SRE_EXTRACT_USERNAME
                 For extracting the username from the auth_header.
           SRE_CHECK_USERNAME
                 For checking whether  a given password matches
                 the password used in auth_header
           SRE_REQFIELD
                  For looking up values of other request headers,
                  such as the Cookie: request header.
           

• If you want to use a custom username procedure for only a subset of supported hosts, you can use the NO_CUSTOM_USERNAME parameter in host-specific SREHTTP2.CFG files (to suppress its use for these hosts).
• Custom username procedures do not have to pay any attention to and of the arguments. In particular, it need not attempt to match client privileges to the Requires list.
• See SREHTTP2\PROCS\CUST_USR.ERX for a simple example of a "custom username" procedure.

III) Outline of Username Lookup

The following outline describes the steps that SREhttp/2 takes whether to grant the client access to the requested resource.

Reviewing: Client privileges can be defined in the SUPERUSER step, in the INHOUSEIPS step, and in the username lookup step. They can also be defined by a custom username procedure. To determine access rights, client privileges are compared to selector-specific required privileges.

Also note that client privileges can be used in other parts of SREhttp/2 (such as by SREhttp/2 addons).