Authentication is the verification of a user's identity, usually through a username/password combination. Authorization is allowing a certain action to be applied to a particular path based on authentication of the originator.
Generally, authorization is a two step process. First authentication, using a username/password database. Second authorization, determining what the username is allowed to do for this transaction.
Authentication environments can get complex very quickly, don't forget to
"keep it simple, stupid", see 9.3.1 - KISS.
Overview
Server authorization is performed using a configuration file, authentication database and optional authorization grouping database, and is based on per-path directives. There is no user-configured authorization necessary, or possible! In the configuration file paths are associated with the authentication and authorization environments, and so become subject to the HTTPd authorization mechanism. Reiterating ... WASD HTTPd authorization administration involves those two aspects, setting authorization against paths and administering the authentication and authorization databases.
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 challenge/failure.
For the WASD HTTPd user authentication can be done via the server system's SYSUAF database (not recommended except when employing SSL or in the most secure of LAN environments) , see 9.6 - SYSUAF-Authenticated Users for further information.
The authentication database name can be refered to as the realm, and refers to a collection of username/passwords. It can be the system's SYSUAF database.
The authorization database can be refered to as the group, and refers to a collection of usernames and associated permissions.
Separate databases are not always necessary, permission information can be
stored in the same database as the password information. Paths are generally
authorized on a per-group basis. Path access can be also be restricted on an
internet host name/domain, internet address and/or authenticated username
basis. If only a small number of usernames are to be associated with a path it
is possible to list them all against the path and have permissions derived
directly from the authentication database (realm).
Authentication Policy
A policy regarding when authorization can be used may be established for the server. This can restrict authentication challenges to "https:" (SSL) requests (see 10 - Secure Sockets Layer), thereby ensuring that the authorization environment is not compromised by use in non-encrypted transactions. Two HTTPd qualifiers provide this.
Note also that individual paths may be restricted to SSL requests using either the mapping conditional rule configuration or the authorization configuration files. See Conditionals and Access Restriction List.
In addition two configuration parameters have a direct role in an established authorization policy.
Details of authentication failures are logged to the HTTPd process log.
The term authorization scheme refers to the HTTP 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 (and therefore easily readable).
- 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.
Both paths and usernames have permissions associated with them. A path may be specified as read-only, read and write, or write-only (yes, I'm sure someone will want this!) A username may be specified as read capable, read and write capable, or only write capable. For each transaction these two are combined to determine the maximum level of access allowed. The allowed action is the logical AND of the path and username permissions.
The permissions may be described using the HTTP method names, or using the more concise abbreviations R, W, and R+W.
| 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 |
Requiring a particular path to be authorized in the HTTP transaction is accomplished by applying authorization requirements against that path in a configuration file. This is an activity distinct from setting up and maintaining any authentication/authorization databases required for the environment.
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]" or "[realm;group]" specification, or with 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 request scheme ("https:") and/or host address(es) and/or username(s).
The following shows the format of an authentication database only (realm) directive.
[authentication-database]
This the format of a directive using both authentication and authorization databases (both realm and group).
[authentication-database ; authorization-database]
/root/path/ group-access-list,group-permissions ; \
world-access-list,world-permissions
The same path cannot be specified against two different
realms. The reason lies in the HTTP authentication schema, which allows
for only one realm in an authentication dialog. How would the server decide
which realm to use in the authentication challenge? Of course, different parts
of a given tree may have different authorizations, however any tree ending in
an asterisk results in the entire sub-tree being controlled by the specified
authorization environment, unless a separate specification exists for some
inferior portion of the tree.
Reserved Realms
The following realm names (authentication database names) are reserved and have special functionality.
By default accounts with SYSPRV authorized are always rejected to discourage the use of 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.
See 9.6 - SYSUAF-Authenticated Users for further information.
The following username is reserved.
If a host name, protocol identifier or username is included in the path configuration directive it acts to further limit access to matching clients (path and username permissions still apply). If more than one are included a request must match each. If multiple host names and/or usernames are included the client must match at least one of each. Host and username 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, while
/web/secret/* https:,*.three.stooges,~Moe,~Larry,~Curly,readapplies the further restriction of access via "https:" (SSL) only.
Note that it more efficient to place protocol and
host restrictions at the front of a list.
9.3 - Authorization Configuration Examples
[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
WASD authorization allows for very simple authorization environments and provides the scope for quite complex ones. The path authentication scheme allows for multiple, individually-maintained authentication and authorization databases that can then be administered by autonomous managers, applying to widely diverse paths, all under the ultimate control of the overall Web administrator.
Fortunately great complexity is not generally necessary.
Most sites would be expected to require only an elementary setup allowing a few selected Web information managers the ability to write to selected paths. This can best be provided with the one authentication database containing read and write permissions against each user, with and access-restriction list against individual paths.
For example. Consider a site with five departments, each of which wishes to have two representatives capable of administering the departmental Web information. There is one authentication database, named after the site:
HYPOTHETICALIn that database are twelve names, the first two the overall Web administrators, capable of administering all authorized paths, another two from each department makes up another ten:
WEB1 r+w WEB2 r+w JOHN r+w PAUL r+w GEORGE r+w RINGO r+w CURLY r+w LARRY r+w MOE r+w SHEMP r+w MAC r+w MYER r+wThe authorization configuration file then contains:
[HYPOTHETICAL]
# allow web masters (!) to use the administration menu
# to revise web configuration files
# world has no access (read or write)
# access is only allowed from a browser on the same system as the HTTPd
/httpd/-/admin/* #localhost,web1,web2,r+w
/ht_root/local/* #localhost,web1,web2,r+w
# allows BOGUS_R_AND_D department representatives to maintain their web
# this may only be done from within the company subnet
# world has read access
/web/dept/bogus_R_and_D/* 150.15.30.*,John,Paul,web1,web2,r+w ; r
# and so on for the rest of the departments
/web/dept/real_R_and_D/* 150.15.30.*,George,Ringo,web1,web2,r+w ; r
# (the next uses line continuation just for illustration)
/web/dept/marketing/* 150.15.30.*,\
Curly,Larry,web1,web2,r+w ;\
read
/web/dept/production/* 150.15.30.*,Moe,Shemp,web1,web2,r+w ; r
/web/dept/inventory/* 150.15.30.*,Mac,Myer,web1,web2,r+w ; r
[WORLD]
# we need a spot for general POSTing (world has no read access)
# (just for the purposes of illustration :^)
/web/world/* r+w
At this point it should be stressed that the HTTPd-specific (HTA)
authentication and group databases are identical in internal structure and
administration, it is merely the role they assume that differentiates them.
The role of the database is purely a function of where they are used in the
configuration file realm directive, the first mentioned becomes the
authentication database, any subsequent, second database assumes the role of
group database (otherwise that role is also assumed by the authentication
database).
Authentication Database
An authentication, or realm database contains usernames and associated passwords. Passwords are verified using this database. Passwords are always stored in encrypted form.
When using an HTTPd-specific database it can also be used to contain per-user permissions, that control access to configured paths. In this role it acts as both realm (authentication) and group (authorization) database.
It is also possible for the system's SYSUAF database to be used for authentication purposes. Of course HTTPd-specific permissions cannot be stored in this database, but if using SYSUAF-authenticated usernames a VMS security profile can be used to control access to served files, see 9.6 - SYSUAF-Authenticated Users.
Warning ... when using Digest authentication, an authentication database
cannot simply be renamed to represent a group-name change, as the database
name is encrypted as part of the MD5 Digest!
Authorization Database
An authorization, or group database, contains a collection of 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).
An authorization database is not always necessary. If only a small number
of users need to be authorized against a given path they can be specified
individually using a "~username" format (see
Access Restriction List).
Database Administration
The same server administration menu is used to administer authentication/authorization databases, see 9.5 - Server Authorization Administration and 11.3 - HTTPd Server Revise.
There is a thirty-one character limit on database names, and a fifteen
character limit on usernames and passwords. All database and user names are
case-insensitive. BASIC authentication scheme passwords are case
insensitive, however DIGEST authentication scheme passwords should
all be either upper or lower case, mixed case will not work.
9.5 - Server Authorization Administration
The same server administration menu is used to maintain both the authentication and authorization databases, see 11.3 - HTTPd Server Revise.
The server authorization databases can be initially set-up by breaking-in to the server, see 11.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 11 - Server Administration for further
detail.
9.6 - SYSUAF-Authenticated Users
The ability to authenticate using the system's SYSUAF is controlled by the
server /SYSUAF qualifier. By default it is disabled.
Further warning ... SYSUAF authentication is not recommended except in
the most secure of LAN environments or when SSL is employed.
Authentication Identifiers
When SYSUAF authentication is enabled, by default all non-privileged, active accounts are capable of authentication. Restriction of this to those actually requiring such a capability is provided using VMS rights identifiers. When the /SYSUAF=ID qualifier is employed a VMS account must possess one of two specific identifiers before it is allowed to be used for server authentication. Note that this mechanism can also allow privileged accounts to be so used ... deploy with discretion!
This identifier provides at most read access.
This identifier provides read and write access (path protections still apply of course).
Other identifiers provide further control for the way in which the authenticated account may be used.
Use of the authenticated account is restricted to "https:" (SSL) requests.
The account is allowed to change it's SYSUAF password (!!). It is recommended this facility only be employed with SSL in place.
Password modification is enabled by including a mapping rule to the internal change script.
map /http/-/change/* /http/-/change/*
The authorization configuration file must provide authenticated access.
[VMS] /httpd/-/change/vms/* https:,r+w
Also see 9.8 - User Password Modification.
This form allows a suitably named identifier to be created for use in providing group-membership via the SYSUAF. Note the double-underscore separating the fixed from the locally specified portion. Using these identifiers it is possible to limit paths to SYSUAF-authenticated accounts possessing the requisite identifier in manner similar to non-SYSUAF-authentication groups. An account possessing the WASD_VMS__TESTING identifier is allowed write access to the path in the following example:
[VMS;TESTING] /web/project/testing/* r+w ; r
All four rights identifiers must exist for the /SYSUAF=ID facility to be used (even though none may be granted to any account). The identifiers may be created using the AUTHORIZE utility with following commands:
$ SET DEFAULT SYS$SYSTEM $ MCR AUTHORIZE UAF> ADD /IDENTIFIER WASD_VMS_R UAF> ADD /IDENTIFIER WASD_VMS_RW UAF> ADD /IDENTIFIER WASD_VMS_HTTPS UAF> ADD /IDENTIFIER WASD_VMS_PWD
They can then be provided to desired accounts using commands similar to the following:
UAF> GRANT /IDENTIFIER WASD_VMS_RW <account>
and removed using:
UAF> REVOKE /IDENTIFIER WASD_VMS_RW <account>
Note that it is possible to create nil-access VMS accounts that may be used solely for WASD server authentication. Create a standard VMS account in a group dedicated for this function, specifying /NOINTERACTIVE /NONETWORK /NOBATCH /FLAG=DISMAIL.
Be aware that, as with all successful authentications, and due to the
WASD internal authentication cache, changing database contents does not
immediately affect access. Any change in the RIGHTSLIST won't be reflected
until the cache entry expires or it is explicitly flushed (see
11.4 - HTTPd Server Action).
SYSUAF and SSL
When SSL is in use (see 10 - Secure Sockets Layer) the username/password authentication information is inherently secured via the encrypted communications of SSL. To enforce access to be via SSL add the following to the HTTPD$MAP configuration file:
/whatever/path/you/like/* "403 Access denied." ![sc:https]or alternatively the following to the HTTPD$AUTH configuration file:
[REALM] /whatever/path/you/like/* https:
Note that this mechanism is applied after any path and method assessment made by the server's authentication schema.
The qualifier /SYSUAF=SSL provides a powerful mechanism for protecting SYSUAF authentication, restricting SYSUAF authenticated transactions to the SSL environment. The combination /SYSUAF=(SSL,ID) is particularly effective.
Also see Authentication Policy.
Security Profile
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.
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 11.4 - 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.
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.
9.7 - 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 ACE on the directory prevents inadvertant mapping/authorization of a path resulting in the ability to write somewhere not intended.
Two different ACEs implement two grades of access.
This example shows a suitable ACE that applies only to the original directory:
$ SET SECURITY directory.DIR -
/ACL=(IDENT=HTTP$SERVER,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
This example shows setting an ACE that will propagate to created files
and importantly, subdirectories:
$ SET SECURITY directory.DIR -
/ACL=((IDENT=HTTP$SERVER,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL), -
(IDENT=HTTP$SERVER,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL))
This example shows a suitable ACE that applies only to the original directory:
$ SET SECURITY directory.DIR -
/ACL=(IDENT=HTTP$SERVER,ACCESS=READ+WRITE+EXECUTE+DELETE)
This example shows setting an ACE that will propagate to created files
and importantly, subdirectories:
$ SET SECURITY directory.DIR -
/ACL=((IDENT=HTTP$SERVER,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE+DELETE), -
(IDENT=HTTP$SERVER,ACCESS=READ+WRITE+EXECUTE+DELETE))
To assist with the setting of the required ACEs an example,
general-purpose DCL procedure is provided,
HT_ROOT:[EXAMPLE]AUTHACE.COM.
9.8 - User Password Modification
The server provides for users to be able to change their own HTA passwords (and SYSUAF if required). 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>