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. "WASD VMS Web Services - Features and Facilities"; 3 - Authentication and Authorization WASD Web Services - Features and Facilities 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.
Changes to the authorization configuration file can be validated at the command-line before reload or restart. This detects and reports any syntactical and configuration errors but of course cannot check the intent of the rules.
$ HTTPD /DO=AUTH=CHECK
If additional server startup qualifiers are required to enable specific authorization features then these must also be provided when checking. For example:
$ HTTPD /DO=AUTH=CHECK /SYSUAF /PROFILE
A server's currently loaded authorization rules may also be interrogated from the Server Administration menu (see "WASD VMS Web Services - Features and Facilities"; 9 - Server Administration WASD Web Services - Features and Facilities ).
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. The examples provided in this section allows access to the WASD online Server Administration facility, and so may be followed specifically for that purpose, as well as serve as a general guide.
$ DEFINE /SYSTEM WASD_STARTUP_SERVER "/SYSUAF=ID" $ @device:[WASD_ROOT.LOCAL]STARTUP.COMAfter a change to a command-line qualifier of the server such as the above it needs to be restarted using the following directive.
$ SET DEFAULT SYS$SYSTEM $ MCR AUTHORIZE UAF> ADD /IDENTIFIER WASD_WEBADMIN
["Web Admin"=WASD_WEBADMIN=id] /httpd/-/admin/* r+w /wasd_root/local/* r+w
$ SET DEFAULT SYS$SYSTEM $ MCR AUTHORIZE UAF> GRANT /IDENTIFIER WASD_WEBADMIN SYSTEM
["Web Admin"=WASD_WEBADMIN=id] /wasd_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 WASD_CONFIG_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
Other sources of authentication are available, either by themselves or used in the same configuration file (different realms and paths) as those already discussed "WASD VMS Web Services - Features and Facilities"; 3.5 - Authentication Sources WASD Web Services - Features and Facilities . Non-SYSUAF sources do not require any startup qualifier to be enabled.
["Whatever you want to call it!"=doi=ACME] /web/area/* r+w
["Whatever you want to call it!"=list-name=list] /web/area/* r+w
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.
["Whatever you want to call it!"=HTA-database-name=HTA] /web/area/* r+w
These databases may be administered using the online Server Administration facility ("WASD VMS Web Services - Features and Facilities"; 9.5 - HTTPd Server Revise WASD Web Services - Features and Facilities or the HTAdmin command-line utility ("WASD VMS Web Services - Features and Facilities"; 13.8 - HTAdmin WASD Web Services - Features and Facilities , are quite secure and versatile.
["Whatever you want to call it!"=agent-name=agent] /web/area/* r+wTwo variations on a versatile LDAP authenticator and a CEL-compatible authenticator, along with example code is available in the WASD_ROOT:[SRC.AGENT] directory.
[X509] /web/area/* r+w
["Whatever you want to call it!"=RFC1413;A_PROJECT=list] /web/area/* r+w ; r
WASD allows separate sources for groups of usernames to control read and write access in a particular realm ("WASD VMS Web Services - Features and Facilities"; 3.6 - Realm, Full-Access, Read-Only WASD Web Services - Features and Facilities . 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 WASD_CONFIG_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. ("WASD VMS Web Services - Features and Facilities"; Access Restriction Keywords WASD Web Services - Features and Facilities .
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
Authentication information is cached. Access subsequently removed or modified will not take effect until the entry expires, or is manually purged using
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