The VMS Authentication Module (VAM) provides users of OpenVMS systems controlled access to user-written applications via an API that the user incorporates into a specific application to control access to that application. The VAM API is described in detail in Chapter 7, “Using the VAM API”.
|
Note: LOCALUAF processing is not offered for the use of the LGI callouts for OpenVMS LOGINOUT.EXE, as this would be redundant with what is offered by OpenVMS.
|
The following sections describe the post-installation setup required to enable the various forms of authentication.
LOCALUAF authentication is supported only for using the VAM callable module. To use the VAM callable module, the system manager must add the line
@install_device:[VAM]VAM_STARTUP
to the SYSTARTUP_VMS.COM file.
Beyond that, no further configuration on the client system is required.
The user will be responsible for using the provided VAM API to integrate VAM into the desired application(s).
Some installations may have several applications protected via VAM and using LOCALAUF processing, but which they want to further restrict access to. For example, the company may want the PAYROLL application restricted to only people from the payroll department, while the INVENTORY application might be restricted to salespeople.
VAM provides a mechanism for restricting access in VAM-enabled applications by using VMS rights identifiers. When adding the VAM interface to an application, the application programmers may add the identifier field to the VMSAuthenticate() function call (see Chapter 7, Using the VAM API, for information on calling VMSAuthenticate). VAM then attempts to match identifier with a rights ID in the UAF record for the username specified in the call to VMSAuthenticate. If a match is made, access is allowed; otherwise, access is denied.
If identifier is not specified or is blank when calling VMSAuthenticate, then identifier will default to VAM_UAF_ID. Therefore, the VAM_UAF_ID rights ID must be granted to all VAM users using LOCALUAF processing if identifier is not specified in the call to VMSAuthenticate.
For example, ABC Corporation has three VAM-enabled applications using LOCALUAF processing: payroll, inventory and personnel. User John Doe will be allowed to access only INVENTORY, while Jane Doe will be allowed to access PERSONNEL and PAYROLL. To set these accounts up, the following steps may be used:
$ run sys$system:authorize
UAF> add/identifier payroll
%UAF-I-RDBADDMSG, identifier PAYROLL value %X80010003 added to rights database
UAF> add/identifier inventory
%UAF-I-RDBADDMSG, identifier INVENTORY value %X80010004 added to rights database
UAF> add/identifier personnel
%UAF-I-RDBADDMSG, identifier PERSONNEL value %X80010005 added to rights database
UAF> grant/identifier inventory johndoe
%UAF-I-GRANTMSG, identifier INVENTORY granted to JOHNDOE
UAF> grant/identifier payroll janedoe
%UAF-I-GRANTMSG, identifier PAYROLL granted to JANEDOE
UAF> grant/identifier personnel janedoe
%UAF-I-GRANTMSG, identifier PERSONNEL granted to JANEDOE
UAF> Exit
%UAF-I-NOMODS, no modifications made to system authorization file
%UAF-I-NAFNOMODS, no modifications made to network proxy database
%UAF-I-RDBDONEMSG, rights database modified
$
Then, when adding VAM to, for example, the payroll application, the call to VMSAuthenticate would be:
status = VMSAuthenticate(“LOCALUAF”, username, 0, &IOCallback,
&InfoCallback, &TimeoutCallback,
&ScreenClearCallback, 0, “payroll”, 0, 0);