Information for the Database Administrator

Data Security with ADABAS

SAS preserves data security provided by ADABAS, NATURAL, and your operating system. As the DBA, you have control over who has security. You control who can create ADABAS files, and creators of the files control who can access the data. Therefore, SAS users can access only ADABAS files they created or ones for which they have been granted specific security options.

To secure data from accidental update or deletion, you can take precautionary measures on both sides of the interface view engine.

How the Interface View Engine Uses Security Specifications

This section contains an explanation of how the interface view engine works in conjunction with both ADABAS Security and the NATURAL SECURITY System (NSS).

The twelve ADABAS Information fields and the three NSS fields discussed in this section can be passed to the interface view engine via a view descriptor or through the use of data set options. For simplicity, it is assumed that each field has been stored in a view descriptor.

If ADABAS Security is in use at your site, up to four separate fields of information might need to be provided for each of three ADABAS files that the interface view engine might reference during the execution of a single SAS procedure. The following are the three ADABAS files:

the file from which data records are to be retrieved and updated (generally referred to as the ADABAS file)
a system file containing DDM information
a security file containing NSS information about the applications and users defined at your site.

The following are the four fields of information associated with each ADABAS file:

file number
password
cipher code
database identifier.

The file number is the number of the ADABAS file from which data records are actually retrieved and updated. The database identifier field indicates which database contains the file. The interface view engine obtains the file number and database identifier from one of two places: either directly from a view descriptor or from a DDM.

If you want to work directly with an ADABAS file (without referencing a DDM), you must supply the file number and database identifier in the view descriptor. (If the ADABAS file is protected using ADABAS Security, you must also supply a password, a cipher code, or both in the view descriptor.) The engine reads the file number and database identifier from the view descriptor and uses them to retrieve and update the appropriate records.

If a DDM name is stored in the view descriptor, the engine obtains the ADABAS file number and database identifier from the DDM. Since a DDM is stored as one or more records in a system file(footnote 1), the engine must read that file to obtain the file number and database identifier.

The system file containing the DDM records is just another ADABAS file. As such, it has a corresponding database identifier and can be security-protected using ADABAS Security. If the system file is protected, you must supply the necessary password and cipher code in the view descriptor. The database identifier must also be stored in the view descriptor.

Once the file number and database identifier are obtained from the DDM, the engine retrieves and updates the appropriate records.

The security file is the third and final ADABAS file that might be referenced by the interface view engine. The security file contains the NATURAL SECURITY data (for each user identifier, application identifier, file, and so on) that are defined at your site.

The interface view engine requires that the security file number, password, cipher code, and database identifier be provided in these situations:

NSS is installed at your site.
The view descriptor refers to a DDM name.
The DDM referenced in the view descriptor has been defined to NSS.
A library identifier, user identifier, and password have been supplied to the engine via the view descriptor or through data set options.

(The security file password and cipher code are required only if the security file has been security-protected using ADABAS security.)

In order to communicate with NSS, the interface view engine needs the security file number, password, cipher code, and database identifier, as well as the NSS library identifier, user identifier, and user password. The engine can use only library identifiers and user identifiers that were previously identified to NSS.

An application program must determine whether a specific library identifier and user identifier have authorization to access or update a particular DDM. To do that, Software AG developed an interface to NSS, which is delivered as a load module named NSCDDM.

The interface view engine uses this NSS interface to check access and update authorization for a library identifier and user identifier. If they do not have the appropriate authorization, an error message is displayed.

SAS Security

To secure data from accidental update or deletion, you can do the following on SAS side of the interface:

Set up all access descriptors yourself. Drop data fields containing sensitive data from display by using the DROP statement.
Set up all view descriptors yourself and give them to users on a selective basis. You can store the appropriate security options in the SAS/ACCESS descriptors, or you might not want to store any options so that users must supply security with data set options. You can also include view WHERE clauses to restrict data access.
Give users read-only access or no access to the SAS library where you store the access descriptors. Read-only access prevents users from editing access descriptors and enables them to see only the data fields selected for each view descriptor.
Set up several access descriptors for multiple security options, or require the user to create them.
Set the ADBUPD systems option to R (for read only) to disable all updates from SAS. See View Engine ADBEUSE System Options Default Values.

ADBSE User Exit

The SAS/ACCESS interface also provides a user exit named ADBSE for execution and access authorization. For information about user exit, contact your SAS support personnel.

Effects of Changing Security Options

The owner of an ADABAS file or NATURAL DDM can change any security option at any time. If a security option that is stored in a view descriptor is changed, you can either update the view descriptor or override the stored option each time you need to use the view descriptor. The software does not require that you use the same option, but either option must have enough authority to service the view descriptor.

Security options can be stored in access descriptors or associated view descriptors. However, changing a security option does not affect access descriptors or view descriptors. The access descriptor still has all its data fields, but you might not be able to use the view descriptor.

Note that if an access descriptor was created with Assign Security=YES, data set options cannot override security specifications included in a SAS/ACCESS view descriptor.

FOOTNOTE 1: Using the NATURAL View Maintenance application (SYSDDM) is one method of defining and cataloging a DDM in a system file. Your site might have more than one NSS system file.

Top of Page