WASD Hypertext Services - Technical Overview

[next] [previous] [contents] [full-page]

9 - Authentication and Authorization

(Could still do with more revision/information!)

Authentication is the verification of a user's identity, usually through a username/password combination. Authorization is allowing a certain action based on authentication of the originator.

The term authorization scheme refers to the method of authenticating the user. The WASD HTTPd can employ one or other, or both of the "Basic" and "Digest" schemes. Both schemes use a username/password mechanism, with Digest being preferable because the password is transmitted encrypted, and with Basic only encoded.

- NOTE -

The Digest scheme has, to date, only been tested against NCSA X Mosaic 2.7-4b, which seems to behave a little flakey when reloading documents, and does not elegantly support stale nonces.

For the WASD HTTPd user authentication can be done via the server system's SYSUAF information (not recommended except in the most secure of LAN environments) (see 9.7 - SYSUAF-Authenticated Users for further information), or using databases specific to the HTTPd environment. The authentication environment is termed the realm, and refers to a grouping of username/passwords as a database.

Authorization is controlled using a configuration file, and is based on per-path directives. There is no user-level authorization configuration necessary, or possible! The authorization environment is termed the group, and refers to a group of usernames and associated permissions. Paths are authorized on a per-group basis. Path access can be further restricted on an internet host name/domain, internet address and/or authenticated username basis.

AUTHORIZATION IS ALWAYS APPLIED TO THE PATH SUPPLIED WITH THE REQUEST, not to the results of any rule mapping that may have occured! This means authorization paths may be administered without ambiguity.

With requests containing a script, authorization is performed on both script and path components. First script access is checked for any authorization, then the path component is independently authorized. Either may result in an authorization failure.

Generally, authorization is a two step process. First, authentication, using a username/password realm database. Second, authorization, looking up a group database to determine what the username is allowed to do within that group. It is possible to use the same database for both authentication and authorization.


9.1 - Permissions, Path and User

Path Permissions

Here the term permission is used to describe a path's ability to be read from and/or written to. When a configuration directive is made against a path the DELETE, GET, HEAD, POST and PUT permissions associated with it control the type of access that may be made. This is used in conjunction with user permissions (see User Permissions) to determine whether the request can actually perform the HTTP method it was made with. The allowed action is the logical AND of the path and user permissions. The abbreviations R, W, and R+W allow a more concise notation.


DELETEGETHEADPOSTPUT
READ or Rnoyesyesnono
WRITE or Wyesnonoyesyes
R+Wyesyesyesyesyes
DELETEyesyesnonono
GETnoyesnonono
HEADnonoyesnono
POSTnononoyesno
PUTnoyesnonoyes

User Permissions

The term permissions is used to describe a username's ability to read and/or write within paths configured against that group. Read permission is technically GET and HEAD HTTP methods, write permission POST and PUT methods. Assigning permissions against usernames can allow some within the group read-only access, while others have update capabilities. This is used in conjunction with path permissions (see Path Permissions) to determine whether the request can actually perform the HTTP method it was made with.


9.2 - Databases, Authentication and Group

Authentication Database

The authentication, or realm database contains usernames and associated passwords. Passwords are always verified using this database. In addition, this database can contain per-user permissions, that control access to configured paths. In this role it acts as both realm and group database. Passwords are stored encrypted. Warning ... if using Digest authentication an authentication database cannot be simply renamed to represent a group-name change, as the database name is encrypted as part of the MD5 Digest!

Group Database

The permissions, or group database, contains usernames and their associated permissions within the group. That is, can that user read and/or write paths configured against that group. A group database is never used for password verification (authentication).

A group database is not always necessary. If only a small number of users must the authorized against a given path they can be specified individually using a "~username" format.


9.3 - Authorization Configuration File

By default, the system-table logical name HTTPD$AUTH locates a common authorization configuration file, unless an individual rule file is specified using a job-table logical name. Simple editing of the file changes the configuration. Comment lines may be included by prefixing them with the hash "#" character, and lines continued by placing the backslash character "\" as the last character on a line.

Configuration directives begin either with a "[realm]" specification, or the forward-slash of a path specification. Following the path specification are HTTP method keywords controlling group and world permissions to the path, and any access-restricting host address(es) or username(s).

Reserved Realms

The following realm names are reserved and have special functionality.

  1. EXTERNAL - Any authentication and authorization will be done in some way by an external CGI script. None is attempted by the server.

  2. WORLD - This refers to any request and is not authenticated in any way, only the permissions associated with the path are applied to the request. The reserved username world becomes the authenticated username.

  3. VMS - Use the VMS system's SYSUAF database to authenticate the username. As username/password pairs are transmitted encoded but not encrypted this is not recommended except in the most secure of LAN environments . Accounts with SYSPRV authorized are always rejected to discourage the transmission of unencrypted passwords for potentially significant usernames (e.g. SYSTEM). Accounts that are disusered, have passwords that have expired or that are captive or restricted are also automatically rejected.

    The ability to authenticate using the system's SYSUAF is controlled by the server /SYSUAF qualifier. By default it is disabled.

    See 9.7 - SYSUAF-Authenticated Users for further information.

Reserved Username

The following username is reserved.

  1. WORLD - If a path is authorized using the WORLD realm the pseudo-authenticated username becomes WORLD. Any log will reflect this username and scripts will access a WWW_REMOTE_USER containing this value. Although not forbidden, it is not recommended this string be used as a username in other realms.

Access Restriction List

If a host name or username is included in the path configuration directive it acts to limit access to matching clients. If both are included a request must match both. If multiple host names and/or usernames are included the client must match at least one of each. Strings may contains the asterisk wildcard, matching one or more consecutive characters. This is most useful when restricting access to all hosts within a given domain, etc.

For example
  /web/secret/* *.three.stooges,~Moe,~Larry,~Curly,read
restricts read access to Curly, Larry and Moe accessing from within the three.stooges network.


9.4 - Authorization Configuration Examples

  1. In the following example the authentication realm is "WASD" and the permissions group "SOCIALCLUB". The directive allows those authenticated from the WASD realm and in the SOCIALCLUB group to read and write, and the world to read.
      [WASD;SOCIALCLUB]
      /web/socialclub/* r+w ; read
    

  2. This example illustrates restricting access according internet address. Both the group and world restriction is identical, but the group address is being specified numerically, while the world access is being specified alphabetically. This access check is done doing simple wildcard comparison, and makes numerical specifications potentially more efficient because they are usually shorter. The second line restricts that path's write access even further, to one username, "BLOGGS".
      [WASD;SOCIALCLUB]
      /web/socialclub/* 131.185.45.*,get,post; *.dsto.defence.gov.au,get
      /web/socialclub/accounts/* 131.185.45.*,~BLOGGS,get,post; *.dsto.defence.gov.au,get
    

  3. In the following example the authentication realm and group are a single database, "ADMIN". The first directive allows those in the ADMIN group to read and write, and the world to read ("get,post;get"). The second line restricts write and even read access to ADMIN group, no world access at all ("get,post").
      [ADMIN]
      /web/everyone/* get,post;get
      /web/select/few/* get,post
    

  4. This example usernames are used to control access to the specified paths. These usernames are authenticated from the COMPANY database.
      [COMPANY]
      /web/docs/* ~Howard,~George,~Fred,r+w ; r
      /web/accounts/* ~George,r+w ; r
    

  5. The following example shows a path specifying the local system's SYSUAF being used to authenticate any usernames. Whenever using SYSUAF authentication it is strongly recommended to limit the potential hosts that can authenticate in this way by always using a host-limiting access restriction list. The world get read access.
      [VMS]
      /web/local/area/* 131.185.250.*,r+w ; r
    

  6. To restrict server administration to browsers executing on the server system itself and the SYSUAF-authenticated username DANIEL use a restriction list similar to the following.
      [VMS]
      /httpd/-/admin/*  #localhost,~daniel,r+w
    

  7. The following example illustrates providing a read and writable area (GET, POST and PUTable) to hosts in the local network without username authentication (carefull!).
      [WORLD]
      /web/scratch/*  *.local.hosts.only,r+w
    


9.5 - Server Authorization Administration

The server authorization databases can be initially set-up by breaking-in to the server, see 9.5.1 - Breaking-in To The Server!.

A server's currently loaded path authorization and user authentication information may be administered and interrogated on-line using the server administration facility. See 10 - Server Administration for further detail.


9.5.1 - Breaking-in To The Server!

The server's authentication/authorization environment can be circumvented under special circumstances. Note that this is not possible without administrator action and persists only as long as the administrator actually performs the action!

This provision exists for only three foreseeable situations:

  1. initial configuration of the authentication environment
  2. loss of the administrator's password
  3. demonstration purposes

Method

If performing the initial authentication configuration make sure the HT_AUTH logical is correctly defined.

Manually start a new instance of the server on a non-standard port using the /PROMISCUOUS qualifier. This can be done at the command-line. There is now a security hole. Example:

  $ HTTPD = "HT_EXE:HTTPD.EXE"
  $ SPAWN /WAIT HTTPD /PORT=8088 /PROMISCUOUS

This will allow access using any username/password combination. Access this instance of the server with a browser and use the server administration menu. It is now possible to create databases, enter username details, change the administrator's password to something known, etc., etc. Shutdown that server again (ctrl-Y) and the security hole disappears.


9.6 - User Password Modification

The server provides for users to be able to change their own passwords. This functionality, though desirable from the administrator's viewpoint, is not mandatory if the administrator is content to field any password changes, forgotten passwords, etc. Keep in mind that passwords, though not visible during entry, are passed to the server using clear-text form fields.

Password modification is enabled by including a mapping rule to the internal change script. For example:

  map /http/-/change/* /http/-/change/*

Any database to be enabled for password modification must have a writable authorization path associated with it. For example:

  [GROUP]
  /httpd/-/change/group/* r+w

  [ANOTHER_GROUP]
  /httpd/-/change/another_group/* r+w

Use some form of cautionary wrapper if providing this functionality:

  <H2>Change Your Authentication</H2>

  <BLOCKQUOTE><I>
  Change the password used to identify yourself to the REALM Web environment for
  some actions.  Note that this <U>not</U> an operating system password, nor has
  it anything to do with it.  Due to the inherent weaknesses of using
  non-encrypted password transmissions on networks <FONT COLOR="#ff0000"><U>DO
  NOT</U> use a password you have in use anywhere else, especially an operating
  system password!</FONT> You need your current password to make the change.  If
  you have forgotten what it is contact <A HREF="/web/webadmin.html">WebAdmin</A>,
  preferably via email, for the change to be made on your behalf.
  </I></BLOCKQUOTE>

  <UL>
  <LI><A HREF="/httpd/-/change/REALM/">REALM</A> realm.
  </UL>


9.7 - SYSUAF-Authenticated Users

The ability to authenticate using the system's SYSUAF is controlled by the server /SYSUAF qualifier. By default it is disabled.

It is possible to control access to files and directories based on the VMS security profile of a SYSUAF-authenticated remote user. This functionality is implemented using VMS security system services involving SYSUAF and RIGHTSLIST information. The feature must be explicitly allowed using the server /PROFILE qualifier. By default it is disabled.

Further warning ... SYSUAF authentication is not recommended except in the most secure of LAN environments.

Note that this mechanism is applied after any path and method assessment made by the server's authentication schema.

When a SYSUAF-authenticated user (i.e. the VMS realm) is first authenticated a VMS security-profile is created and stored in the authentication cache. A cached profile is an efficient method of implementing this as it obviously removes the need of creating a user profile each time a resource is assessed. If this profile exists in the cache it is attached to each request authenticated for that user. As it is cached for a period, any change to a user's security profile in the SYSUAF or RIGHTSLIST won't be reflected in the cached profile until the cache entry expires or it is explicitly flushed (see 10.3 - HTTPd Server Action).

When a request has this security profile all accesses to files and directories are assessed against it. When a file or directory access is requested the security-profile is employed by a VMS security system service to assess the access. If allowed, it is provided via the SYSTEM file protection field. Hence it is possible to be eligible for access via the OWNER field but not actually be able to access it because of SYSTEM field protections! If not allowed, a "no privilege" error is generated.

Of course, this functionality only provides access for the server, IT DOES NOT PROPAGATE TO ANY SCRIPT ACCESS. If scripts must have a similar ability they should implement their own scheme (which is not too difficult, see HT_ROOT:[SRC.MISC]CHKACC.C ) based on the CGI variable WWW_AUTH_REALM which would be "VMS" indicating SYSUAF-authentication, and the authenticated name in WWW_REMOTE_USER.

Controlling Server Write Access

Write access by the server into VMS directories (using the POST or PUT HTTP methods) is controlled using VMS ACLs. This is in addition to the path authorization of the server itself of course! The requirement to have an ACL on the directory prevents inadvertant mapping/authorization of a path resulting in the ability to write somewhere not intended.

Two different ACLs implement two grades of access.

  1. If the ACL grants CONTROL access to the server account then only VMS-authenticated usernames with security profiles can potentially write to the directory. Only potentially, because a further check is made to assess whether that VMS account in particular has write access.

    This example shows a suitable ACL that applies only to the original directory:

      $ SET SECURITY directory.DIR -
        /ACL=(IDENT=HTTP$SERVER,ACCESS=READ+CONTROL)
    
    This example shows setting an ACL that will propagate to created files and importantly, subdirectories:
      $ SET SECURITY directory.DIR -
        /ACL=((IDENT=HTTP$SERVER,OPTIONS=DEFAULT,ACCESS=READ+WRITE+DELETE+CONTROL), -
              (IDENT=HTTP$SERVER,ACCESS=READ+WRITE+DELETE+CONTROL))
    
  2. If the ACL grants WRITE access then the directory can be written into by any authenticated username for the authorized path.

    This example shows a suitable ACL that applies only to the original directory:

      $ SET SECURITY directory.DIR -
        /ACL=(IDENT=HTTP$SERVER,ACCESS=READ+WRITE)
    
    This example shows setting an ACL that will propagate to created files and importantly, subdirectories:
      $ SET SECURITY directory.DIR -
        /ACL=((IDENT=HTTP$SERVER,OPTIONS=DEFAULT,ACCESS=READ+WRITE+DELETE), -
              (IDENT=HTTP$SERVER,ACCESS=READ+WRITE+DELETE))
    

Performance Impact

If the /PROFILE qualifier has enabled SYSUAF-authenticated security profiles, whenever a file or directory is assessed for access an explicit VMS security system service call is made. This call builds a security profile of the object being assessed, compares the cached user security profile and returns an indication whether access is permitted or forbidden. This is addition to any such assessments made by the file system as it is accessed.

This extra security assessment is not done for non-SYSUAF-authenticated accesses within the same server.

For file access this extra overhead is negligible but becomes more significant with directory listings ("Index of") where each file in the directory is independently assessed for access.


[next] [previous] [contents] [full-page]