Authentication is the verification of a user's identity, usually through username/password credentials. 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 11.7.1 - KISS.
Overview
Server authorization is performed using a configuration file, authentication source, and optional full-access and read-only authorization grouping sources, 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 sources.
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. This beahviour can be disbaled using a path SETting rule, see 9.2.5 - SET Rule.
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 11.9 - SYSUAF-Authenticated Users for further information.
The authentication source name is refered to as the realm, and refers to a collection of usernames and passwords. It can be the system's SYSUAF database.
The authorization source is refered to as the
group, and refers to a collection of usernames and associated
permissions.
11.1 - Authentication Policy
A policy regarding when and how authorization can be used may be established on a per-server basis. This can restrict authentication challenges to "https:" (SSL) requests (see 13 - 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.
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.
|
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]", "[realm;group]" or "[realm;group-r+w;group-r]" 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).
Square brackets are used to enclose a [realm;group;group] specification, introducing a new authentication grouping. Within these brackets is specified the realm name (authentication source), and then optional group (authorization source) names separated by semi-colons. All path specifications following this are authenticated against the specified realm database, and permissions obtained from the group d"[realm;group]" database (or authentication database if group not specified), until the next [realm;group;group] specification.
The following shows the format of an authentication source (realm) only directive.
[authentication-source]
This one, the format of a directive using both authentication and authorization sources (both realm and group).
[authentication-source ; authorization-source]
The third variation, using an authentication, full-access (read and write) and read-only authorization sources (realm and two grouping).
[authentication-source ; full-access-source ; read-only-source]
The authentication source may also be given a description. This is the text the browser dialog presents during password prompting. See Realm Description in 11.4 - Authorization Sources.
Paths are usually specified terminated with an asterisk wildcard. This implies that any directory tree below this is included in the access control. Wildcards may be used to match any portion of the specified path, or not at all. Following the path specification are control keywords representing the HTTP methods or permissions that can be applied against the path, and optional access-restricting list of host address(es) and/or username(s), separated using commas. Access control is against either or both the group and the world. The group access is specified first followed by a semi-colon separated world specification. The following show the format of the path directive, see the examples below to further clarify the format.
/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.
There is a thirty-one character limit on authentication source names, and a
fifteen character limit on usernames and passwords. All source 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.
Reserved Names
The following 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.
The authentication source may be disguised by giving it a specific description. This will the text the browser dialog presents during password prompting. See Realm Description in 11.4 - Authorization Sources.
See 11.9 - SYSUAF-Authenticated Users for further information on these topics.
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.
11.4 - Authorization Sources
Username authorization information may be derived from several sources, each with different characteristics.
An identifier is indicated by appending a "=ID" to the name of the realm or group. Also refer to 11.9.1 - Rights Identifiers.
Whether or not any particular username is allowed to authenticate via the SYSUAF may be controlled by that account holding or not holding a particular rights identifier. Placing "=ID" against realm name implies the username must exist in the SYSUAF and hold the specified identifier name.
[PROJECT_A=id]
When (and only when) a username has been authenticated via the SYSUAF, rights identifiers associated with that account may be used to control the level-of-access within that realm. This is in addition to any identifier controlling authentication itself.
[PROJECT_A=id;PROJECT_A_LIBRARIAN=id;PROJECT_A_USER=id]
In this example a username would need to hold the PROJECT_A identifier to be able to authenticate, PROJECT_A_LIBRARIAN to write the path(s) (via POST, PUT) and PROJECT_A_USER to be able to read the path(s).
The server system SYSUAF may be used to authenticate usernames using the VMS account name and password. The realm being VMS may be indicated by using the name "VMS", by appending "=VMS" to another name making it a VMS synonym, or by giving it a specific description (see Realm Description in 11.4 - Authorization Sources). Further information on SYSUAF authentication may be found in 11.9 - SYSUAF-Authenticated Users. These examples illustrate the general idea.
[VMS] [LOCAL=vms] [ANY_NAME_AT_ALL=vms]
A plain-text list may be used to provide usernames for group membership. The format is one username per line, at the start of the line, with optional, white-space delimited text continuing along the line (which could be used as documentation). Blank lines and comment lines are ignored. A line may be continued by ending it with a "\" character. These files may, of course, be created and maintained using any plain text editor. They must exist in the HT_AUTH: directory, have an extension of ".HTL", and do not need to be world accessable.
# the stooges curley Jerome Horwitz larry Louis Feinberg moe Moses Horwitz shemp Samuel Horwitz JoeBesser JoeDeRita
Simple lists are indicated in the configuration by appending a "=LIST" to the name.
[VMS;STOOGES=list]
It also possible to use a simple list for authentication purposes. The plain-text password is appended to the username with a trailing equate symbol. Although in general this is not recommended as everything is stored as plain-text it may be suitable as an ad hoc solution in some circumstances. The following example shows the format.
# silly example fred=dancesalittle Guess who? ginger=rogers No second prizes!
These are binary, fixed 512 byte record files, containing authentication and authorization information. HTA databases may be used for authentication and group membership purposes. The content is much the same, the role differs according to the location in the realm directive. The contents these files must be accessed and modified via the server administration menu. See 14.3 - HTTPd Server Revise. They are located in the HT_AUTH: directory and have an extension of ".HTA".
(Essentially for historical reasons) HTA databases are the default sources for authorization information. Therefore, using just a name, with no trailing "=something", will configure an HTA source. Also, and recommended for clearly showing the intention, appending the "=HTA" qualifier specifies an HTA database. The following example show some of the variations.
[VMS;PROJECT_A=hta] [DEVELOPERS=hta;PROJECT_A=hta]
An authorization agent is a CGI-compliant script that is specially activated during the authorization processing. Using CGI environment variables it gets details of the request, makes an assessment based on it's own internal authentication/authorization processing, and using the script callout mechanism returns it's results to the server, which then acting on these, allows or denies access.
Such agents allows a site to develop local authentication/authorization mechnisms relatively easily, based on CGI principles. A discussion of such a development is not within the scope of this section, see the WASD Scripting Environment document for information on the use of callouts, and the example and working authorization agents provided in the HT_ROOT:[SRC.AGENT] directory. The description at the beginning of these programs covers these topics in some detail.
An authorization agent would be configured using something like the following, where the "AUTHAGENT" is the actual script name doing the authorization. This has the the path "/cgiauth-bin/" prepended to it.
["Example Agent"=AUTHAGENT_EXAMPLE=agent] /some/path/or/other/* r+w
It is possible to supply additional, per-path information to an agent. This can be any free-form text (up to a maximum length of 63 characters). This might be a configuration file location, as used in the example CEL authenticator. For example,
["CEL Authenticator"=AUTHAGENT_CEL=agent] /some/path/or/other/* r+w,param=HT_ROOT:[LOCAL]CEL1.LIS /a/nother/path/* r+w,param=HT_ROOT:[LOCAL]CEL2.LIS
It is necessary to have the following entry in the HTTPD$MAP configuration file:
exec+ /cgiauth-bin/* /cgi-bin/*
This implies that authentication agents are always CGIplus scripts (technically it's possble for vanilla CGI script to be agents, but for efficiency reasons this is discouraged). It also allows authentication scripts to be located outside of the general server tree if desired.
A realm directive may contain one or more different types of authorization information source, with the following restrictions.
[DEVELOPERS;PROJECT_A=id] [DEVELOPERS=hta;LIBRARIAN=id;PROJECT_A=list] [STOOGES=list;MOE_HOWARD=id]
It is possible to supply text describing the authentication realm to the browser user that differs from the actual source name. This may be used to disguise the actual source or to provide a more informative description than the source name conveys.
Prefixing the actual realm source name with a double-quote delimited string (of up to 31 characters) and an equate symbol will result in the string being sent to a browser as the realm description during an authentication challenge. Here are some examples.
["the local host"=VMS] ["Social Club"=SOCIAL_CLUB_RW=id] ["Finance Staff"=FINANCE=list] ["Just Another Database"=DBACCESS=hta]
NOTE
The Digest authentication scheme uses the realm description at both server and browser in the encrypted password challenge and response. When passwords are stored in an HTA file this realm synonym cannot be changed without causing these passwords to be rendered invalid.
WASD authorization offers a number of combinations of access control. This is a summary. Please note that when refering to the level-of-access a particular username may be allowed (read-only or full, read-write access), that it is always moderated by the level-of-access provided with a path configured within that realm. See 11.2 - Permissions, Path and User.
When a path is controlled by a realm that comprises an authentication source only, as in this example
[authentication-source]usernames authenticated using that are granted full (read and write) access.
Where a group membership source is provided following the authentication source, as illustrated in this example
[authentication-source;group-source]the level-of-access depends on the source of the group membership. If from a simple-list of usernames or via a VMS rights identifier the username receives full (read and write) access. If from an HTA database the access is dependent on what is set against that user in the database. It can be either full or read-only.
When a second group is specified, as in
[authentication-source;group-source;group-source]the authentication is interpreted in a fixed fashion. The first group specified contains usernames to be granted full (read and write) access. The second group read-only access. Should a username occur in both groups full access takes precedence.
As described in 6.2 - Virtual Services, virtual service syntax may be used with authorization mapping to selectively apply rules to one specific service. This example provides the essentials of using this syntax. Note that service-specific and service-common rules may be mixed in any order allowing common authorization environments to be shared.
# authorization rules example for virtual servers [[alpha.wasd.dsto.defence.gov.au:443]] # ALPHA SSL is the only service permitting VMS (SYSUAF) authentication [LOCAL=vms] /web/* https:,r+w ; r /httpd/-/admin/* ~daniel,https:,r+w [[beta.wasd.dsto.defence.gov.au:80]] # BETA has it's own HTA database [BETA_USER=hta] /web/* r+w ; r [[gamma.wasd.dsto.defence.gov.au:80]] # GAMMA likewise [GAMMA_DEVELOPER=id;PROJECT-A=list] /web/project/a/* r+w ; r [GAMMA_DEVELOPER=id;PROJECT-B=list] /web/project/b/* r+w ; r [[*]] # allow anyone from the local subnet to upload to here [WORLD] /web/unload/* 131.185.200.*,r+w
The server administration menu path authorization report (see
14.2 - HTTPd Server Reports) provides a selector allowing the viewing and
checking of rules showing all services or only one particular virtual server,
making it simpler to see exactly what any particular service is authorizing
against.
11.7 - Authorization Configuration Examples
Mixed case is used in the configuration examples (and should be in configuration files) to assist in readability. Rule interpretation however is completely case-insensitive.
[WASD=vms;SOCIALCLUB=list] /web/socialclub/* r+w ; read
[WASD=vms;SOCIALCLUB=list] /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
[DEVELOPER=id;PROJECT_A_LIBRARIAN=id;PROJECT_A_USER=id] /web/projects/a/* r+w /web/projects/* r
[ADMIN=hta] /web/everyone/* get,post;get /web/select/few/* get,post
["The Company"=COMPANY=hta] /web/docs/* ~Howard,~George,~Fred,r+w ; r /web/accounts/* ~George,r+w ; r
[VMS] /web/local/area/* 131.185.250.*,r+w ; r
["not the VMS SYSUAF"=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 three departments, each of which wishes to have three representatives capable of administering the departmental Web information. Authentication is via the SYSUAF. Web administrators hold an approriate VMS rights identifier, "WEBADMIN". Department groupings are provided by three simple lists of names, including the Web administrators (whose rights identifier would not be applied if access control is via a simple list), a fourth lists those with read-only access into the Finance area. The four grouping files would look like:
# Department 1 # Department 2 WEB1 WEB1 WEB2 WEB2 JOHN RINGO PAUL CURLY GEORGE LARRY # Department 3 # Finance (read access) WEB1 PAUL WEB2 GEORGE MOE JOHN SHEMP RINGO MACThe authorization configuration file then contains:
####################################################################### # 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 in the same subnet as the HTTPd ["Hypo Thetical Corp."=HYPOTHETICAL=vms;WEBADMIN=id] /httpd/-/admin/* #150.15.30.*,r+w /ht_root/local/* #150.15.30.*,r+w # allows Department 1 representatives to maintain their web # this may only be done from within the company subnet # world has read access ["Hypo Thetical Corp."=HYPOTHETICAL=vms;DEPARTMENT1=list] /web/dept/general/* 150.15.30.*,r+w ; r # and so on for the rest of the departments ["Hypo Thetical Corp."=HYPOTHETICAL=vms;DEPARTMENT2=list;FINANCE=list] # no world read access into finance, only those in the FINANCE list /web/dept/finance/* 150.15.30.*,r+w ["Hypo Thetical Corp."=HYPOTHETICAL=vms;DEPARTMENT3=list] /web/dept/inventory/* 150.15.30.*,r+w ; r /web/dept/production/* 150.15.30.*,r+w ; r # (the next uses line continuation just for illustration) /web/dept/marketing/* 150.15.30.*,\ r+w ;\ read # we need an area for general POSTing (just for illustration :^) [WORLD] /web/world/* r+w #######################################################################
Access to authentication sources, SYSUAF, simple lists and HTA databases, are relatively expensive operations. To reduce the impact of this activity on request latency and general server performance authentication and realm-associated permissions for each authenticated username are stored in a cache. This means that only the initial request needs to be checked from appropriate databases, subsequent ones are resolved more quickly and efficiently from cache.
Such cached entries have a finite lifetime associated with them. This
ensures that authorization information associated with that user is regularly
refreshed. This period, in minutes, is set using the [AuthCacheMinutes]
configuration parameter. Zero disables caching with a consequent impact on
performance.
Implication
Where-ever a cache is employed there arises the problem of keeping the contents current. The simple lifetime on entries in the authentication cache means they will only be checked for currency whenever it expires. Changes may have occured to the databases in the meantime.
Generally there is are other considerations when adding user access. Previously the user attempt failed (and was evaluated each time), now the user is allowed access and the result is cached.
When removing or modifying access for a user the cached contents must be
taken into account. The user will continue to experience the previous level of
access until the cache lifetime expires on the entry. When making such changes
it is recommended to explicitly purge the authentication cache either from the
command line using /DO=AUTH=PURGE (see 5.3.2 - Server Command Line Control) or via
the server administration menu (see 14 - Server Administration). Of
course the other solution is just to disable caching, which is a less than
optimal solution.
11.9 - SYSUAF-Authenticated Users
The ability to authenticate using the system's SYSUAF is controlled by the
server /SYSUAF[=keyword] 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.
By default accounts with SYSPRV authorized are always rejected to
discourage the use of potentially significant usernames (e.g. SYSTEM). This
behaviour can be changed through the use of specific identifiers, see
11.9.1 - Rights Identifiers immediately below. Accounts that are
disusered, have passwords that have expired or that are captive or restricted
are always rejected. Accounts that have access time restricting REMOTE or
NETWORK access will have those restrictions honoured (see
11.9.1 - Rights Identifiers for a workaround for this.)
11.9.1 - Rights Identifiers
Whether or not any particular username is allowed to authenticate via the SYSUAF may be controlled by that account holding or not holding a particular VMS rights identifier. When a username has been authenticated via the SYSUAF, rights identifiers associated with that account may be used to control the level-of-access within that realm.
Use of identifiers for these purposes are enabled using the /SYSUAF=ID server startup qualifier.
Three reserved identifier names are optional. A warning will be reported during startup if these are not found.
Identifiers may be managed using the following commands. If unsure of the security implications of this action consult the relevant VMS system management security documentation.
$ SET DEFAULT SYS$SYSTEM $ MCR AUTHORIZE UAF> ADD /IDENTIFIER WASD_HTTPS_ONLY UAF> ADD /IDENTIFIER PROJECT_USER UAF> ADD /IDENTIFIER PROJECT_DEVELOPER UAF> ADD /IDENTIFIER PROJECT_LIBRARIAN
They can then be provided to desired accounts using commands similar to the following:
UAF> GRANT /IDENTIFIER PROJECT_USER <account>
and removed using:
UAF> REVOKE /IDENTIFIER PROJECT_USER <account>
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.8 - Authorization Cache).
11.9.2 - WASD "Hard-Wired" Identifiers
Deprecated and Discouraged
This description is included for reasons of backward compatibility. As of version 6.0 the WASD identifiers must be enabled using the /SYSUAF=WASD qualifier.
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=WASD 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! Note also that the use of access identifiers with this facility allows a much finer control of which accounts may be used for authentication and so is also the prefered mechanism for deploying SYSUAF authentication.
- WASD_VMS_R
This identifier provides at most read access.
- WASD_VMS_RW
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.
- WASD_VMS_HTTPS
Use of the authenticated account is restricted to "https:" (SSL) requests.
- WASD_VMS_PWD
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 /httpd/-/change/* /httpd/-/change/*The authorization configuration file must provide authenticated access.
[VMS] /httpd/-/change/vms/* https:,r+wAlso see 11.12 - User Password Modification.
- WASD_VMS__<group-name>
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 ; rAll 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_PWDThey 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>
It is possible, and may be quite effective for some environments, to have a SYSUAF account or accounts strictly for HTTP authorization, with no actual interactive or other access allowed to the VMS system itself. This would relax the caution on the use of SYSUAF authentication outside of SSL transactions. An obvious use would be for the HTTP server administrator. Additional accounts could be provided for other authorization requirements, all without compromising the system's security.
In setting up such an environment it is vital to ensure the HTTPd server is started using the /SYSUAF=ID qualifier (see 11.1 - Authentication Policy). This will require all SYSUAF-authenticated accounts to possess a specific VMS resource identifier, accounts that do not possess the identifier cannot be used for HTTP authentication. In addition the identifier WASD_NIL_ACCESS will need to be held (see 11.9.1 - Rights Identifiers), allowing the account to authenticate despite being restricted by REMOTE and NETWORK time restrictions.
To provide such an account select a group number that is currently unused for any other purpose. Create the desired account using whatever local utility is used then activate VMS AUTHORIZE and effectively disable access to that account from all sources and grant the appropriate access identifier (see 11.9.1 - Rights Identifiers above).
$ SET DEFAULT SYS$SYSTEM $ MCR AUTHORIZE UAF> MODIFY <account> /NOINTERACTIVE /NONETWORK /NOBATCH /FLAG=DISMAIL UAF> GRANT /IDENTIFIER WASD_VMS_RW <account>
When SSL is in use (see 13 - 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 11.1 - Authentication Policy.
11.9.5 - 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.
NOTE: Use caution when deploying the /PROFILE qualifier. It was really designed with a very specific environment in mind, that of an Intranet where the sole purpose was to provide VMS users access to their normal VMS resources via a Web interface.
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 (see 11.8 - Authorization 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 14.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.
11.10 - Controlling Server Write Access
The server account should have no direct write access to into any directory structure. Files in these areas should be owned by SYSTEM ([1,4]). Write access for the server into VMS directories (using the POST or PUT HTTP methods) should be controlled using VMS ACLs. This is in addition to the path authorization of the server itself of course! The recommendation to have no ownership of files and provide an ACE on required directories 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.
11.11 - Securing All Requests
Some sites may be sensitive enough about Web resources that the possibility of providing inadvertant access to some area or another is of major concern. WASD provides a facility that will automatically deny access to any path that does not appear in the authorization configuration file. This does mean that all paths requiring access must have authorization rules associated with them, but if something is missed some resource does not unexpectedly become visible.
At server startup the /AUTHORIZE=ALL qualifier enables this facility.
For paths that require authentication and authorization the standard realms and rules apply. To indicate that a particular path should be allowed access, but that no authorization applies the "NONE" realm may be used. The following example provides some indication of how it should be used.
# allow the librarian to update this area, world to read it [VMS;LIBRARIAN=id] /web/library/* r+w ; read # indicate there is no authorization to be applied [NONE] # allow access to general web areas /web/* # allow access to the HT_ROOT tree /ht_root/*
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 /httpd/-/change/* /httpd/-/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 e-mail, for the change to be made on your behalf. </I></BLOCKQUOTE> <UL> <LI><A HREF="/httpd/-/change/REALM/">REALM</A> realm. </UL>
The reason authorization information is not required to be reentered on subsequent accesses to controlled paths is cached information the browser maintains. It is sometimes desirable to be able to access the same path using different authentication credentials, and correspondingly it would be useful if a browser had a purge authorization cache button, but this is commonly not the case. To provide this functionality the server must be used to "trick" the browser into cancelling its authorization information for a particular path.
This is achieved by adding a specific query string to the path requiring cancellation. The server detects this and returns an authorization failure status (401) regardless of the contents of request "Authorization:" field. This results in the browser flushing that path from it's authorization cache, effectively requiring new authorization information the next time that path is accessed.
The basic procedure is as follows.
/the/current/path?httpd=cancel