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 UserPath 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.
9.2 - Databases, Authentication and GroupAuthentication 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).
The following realm names are reserved and have special functionality.
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.
The following username is reserved.
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.
/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
[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
[ADMIN] /web/everyone/* get,post;get /web/select/few/* get,post
[COMPANY] /web/docs/* ~Howard,~George,~Fred,r+w ; r /web/accounts/* ~George,r+w ; r
[VMS] /web/local/area/* 131.185.250.*,r+w ; r
[VMS] /httpd/-/admin/* #localhost,~daniel,r+w
[WORLD] /web/scratch/* *.local.hosts.only,r+w
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:
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>
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.
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))
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))
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.