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) , 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.
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.
7.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.
DELETE | GET | HEAD | POST | PUT | |
---|---|---|---|---|---|
READ or R | no | yes | yes | no | no |
WRITE or W | yes | no | no | yes | yes |
R+W | yes | yes | yes | yes | yes |
DELETE | yes | yes | no | no | no |
GET | no | yes | no | no | no |
HEAD | no | no | yes | no | no |
POST | no | no | no | yes | no |
PUT | no | yes | no | no | yes |
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.
7.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.
7.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).
The following realm names are reserved and have special functionality.
If a host name or user name 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.
/web/secret/* *.three.stooges,~Moe,~Larry,~Curly,readrestricts read access to Curly, Larry and Moe accessing from within the three.stooges network.
[WASD;SOCIALCLUB] /web/socialclub/* r+w ; read
In this 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/* 131.185.45.*,get,post; *.dsto.defence.gov.au,get /web/socialclub/accounts/* 131.185.45.*,~BLOGGS,get,post; *.dsto.defence.gov.au,get
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''.
[ADMIN] /web/everyone/* get,post;get /web/select/few/* get,post
In this 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'').
[COMPANY] /web/docs/* ~Howard,~George,~Fred,r+w ; r /web/accounts/* ~George,r+w ; r
This example usernames are used to control access to the specified paths. These usernames are authenticated from the COMPANY database.
[VMS] /web/local/area/* ~Daniel,r+w ; r
This example shows a path specifying the local system's SYSUAF be used to
authenticate the username.
7.5 - Server Authorization Administration
The server authorization databases can be initially set-up by breaking-in to the server, see 7.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 8 - HTTPd Server Administration for further
detail.
7.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:
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.
7.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>