WASD Hypertext Services - Technical Overview

WASD offers a comprehensive and versatile authentication and authorization environment.  A little too comprehensive, often leaving the new administrator wondering where to begin.  The role of this chapter is to provide a starting place, especially for sources of authentication, along with some basic configurations.  12 - Authentication and Authorization contains a detailed explanation of all aspects.  All examples here assume a standard installation and environment. 

Just to clarify.  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 that identity. 

11.1 - SYSUAF/Identifier Authentication

This setup allows any active account to authenticate using the local VMS username and password.  By default not every account may authenticate this way, only those holding specified VMS rights identifiers.  See 12.9.1 - Rights Identifiers.  The examples provided in this section allows access to the WASD server administration menus, and so may be followed specifically for that purpose, as well as serve as a general guide. 

• Define the following logical before calling the server startup procedure.  To make such a definition permanent add it to the system or Web environment startup procedures.  This logical contains a startup qualifier that configures the server to allow authentication from the SYSUAF, using VMS rights identifiers.  See 12.1 - Authentication Policy. 

    $ DEFINE /SYSTEM HTTPD$STARTUP_SERVER "/SYSUAF=ID"
    $ @device:[HT_ROOT.LOCAL]STARTUP.COM
  

• Decide on an identifier name.  This can be an existing identifier, or one created for the purpose.  For this example the identifier will be "WASD_WEBADMIN".  Any identifier can be created using actions similar to the following example. 

    $ SET DEFAULT SYS$SYSTEM
    $ MCR AUTHORIZE
    UAF> ADD /IDENTIFIER WASD_WEBADMIN
  

• Modify the authorization configuration file, accessed by the server using the system logical HTTPD$AUTH, to contain the following.  This allows full access to the Administration Menu and [.LOCAL] directory (and no world access).  Additional paths may be added as required, and of course multiple identifiers may be created and used for multiple realms and paths. 

    ["Web Admin"=WASD_WEBADMIN=id]
    /httpd/-/admin/* r+w
    /ht_root/local/* r+w
  

• The identifier must then be granted to those accounts allowed to authenticate in this way. 

    $ SET DEFAULT SYS$SYSTEM
    $ MCR AUTHORIZE
    UAF> GRANT /IDENTIFIER WASD_WEBADMIN SYSTEM
  

• Using this approach useful discrimination may be exercised.  For instance, one identifier for Web administrators, another (or others) for different authentication requirements. 

    ["Web Admin"=WASD_WEBADMIN=id]
    /ht_root/local/* r+w
    /httpd/-/admin/* r+w
    ["Area Access"=area-identifier-name=id]
    /web/area/* r+w ; r
  

  Of course the one account may hold multiple identifiers and so may have access to various areas. 

    UAF> GRANT /IDENTIFIER WASD_WEBADMIN SYSTEM
    UAF> GRANT /IDENTIFIER area-identifier-name SYSTEM
  

  Using VMS rights identifiers allows significant granularity in providing access. 

If the HTTPD$AUTH configuration file is changed, or rights identifiers are granted or revoked from accounts, the server should be directed to reload the file and purge any cached authorization information. 

  $ HTTPD/DO=AUTH=LOAD
  $ HTTPD/DO=AUTH=PURGE

The use of rights identifiers (described above) is strongly recommended.  However if this is impractical for some reason, an alternative setup allows any active, non-privileged account to authenticate using the server system VMS username and password. 

• Define the following logical before calling the server startup procedure.  This logical configures the server to allow authentication from the SYSUAF.  See 12.1 - Authentication Policy. 

    $ DEFINE /SYSTEM HTTPD$STARTUP_SERVER "/SYSUAF"
    $ @device:[HT_ROOT.LOCAL]STARTUP.COM
  

• Modify the authorization configuration file, accessed by the server using the system logical HTTPD$AUTH, to contain the following.  This allows full access to the Administration Menu and [.LOCAL] directory (and no world access at all).  Additional paths may be configured as required. 

    ["Whatever you want to call it!"=VMS]
    /web/area/* r+w
  

  Update access (read+write) may be provided to the authorized and read-only access to the world using syntax similar to the following example.  This applies to all authentication sources. 

    /web/area/* r+w ; r
  

• With no discrimination on which accounts can and cannot authenticate using this setup additional controls on what can be accessed must be supplied.  This is done using either restriction lists (see Access Restriction List)

    ["Realm Name"=VMS]
    /web/area1/* r+w,~username1,~username2
    /web/area2/* r+w,#host1,#host2,~username3
  

  or using access groups (see 11.4 - Read and Write Groupings)

    ["Realm Name"=VMS;list_name1=list]
    /web/area1/* r+w ; 
    ["Realm Name"=VMS;list_name2=list]
    /web/area2/* r+w ; r
  

NOTE

---

To also allow privileged accounts to authenticate via the SYSUAF with this configuration change the logical definition as follows. 

  $ DEFINE /SYSTEM HTTPD$STARTUP_SERVER "/SYSUAF=RELAXED"

This is not a recommended configuration. 
Using VMS identifiers is a far better solution.  See previous section. 

---

Other sources of authentication are available, either by themselves or used in the same configuration file (different realms and paths) as those already discussed.  See 12.4 - Authorization Sources.  Non-SYSUAF sources do not require any startup qualifier to be enabled. 

• Simple lists contain usernames and unencrypted passwords.  These are plain-text files, created and modified using any desired editor. 

    ["Whatever you want to call it!"=list-name=list]
    /web/area/* r+w ; r
  

  This is a very simple arrangement, with little inherent security.  Lists are more useful when grouping names together for specifying which group may do what to where. 

• HTA databases are WASD-specific, binary repositories of usernames, encrypted passwords, capabilities, user and other detail. 

    ["Whatever you want to call it!"=HTA-database-name=HTA]
    /web/area/* r+w ; r
  

  These databases may be administered using the Administration Menu, are quite secure and versatile. 

• External agents are authentication and authorization scripts executed on demand, under the control-of but external to the server.  It is possible for a site to write it's own, custom authorization agent. 

    ["Whatever you want to call it!"=agent-name=agent]
    /web/area/* r+w ; r
  

WASD allows separate sources for groups of usernames to control read and write access in a particular realm.  See 12.5 - Realm, Full-Access, Read-Only.  These groups may be provided via simple lists, VMS identifiers, HTA databases and authorization agents.  The following example shows an identifier authenticated realm with full and read-only access controlled by two simple lists.  For the first path the world has no access, for the second read-only access (with the read-only grouping becoming basically redundant information). 

  ["Realm Name"=identifier_name=id;full_access_name=list;read-only_name=list]
  /web/area/* r+w ; 
  /web/another-area/* r+w ; r

Multiple authentication sources (realms) may be configured in the one HTTPD$AUTH file. 

Multiple paths may be mapped against a single authentication source. 

Any path may be mapped only once (for any single virtual service). 

Paths may have additional access restrictions placed on them, including client host name, username, etc.  See Access Restriction List. 

The configuration file is loaded and stored by the server at startup.  If changed it must be reloaded to take effect.  This can be done manually using

  $ HTTPD/DO=AUTH=LOAD

Authentication information is cached.  Access subsequently removed or modified will not take effect until the entry expires, or is manually purged using

  $ HTTPD/DO=AUTH=PURGE

Failed attempts to authenticate against a particular source are limited.  When this is exceeded access is always denied.  If this has happened the cache must be manually purged before a user can successfully authenticate

  $ HTTPD/DO=AUTH=PURGE