This document covers the following:
The Adabas database security utility ADASCR provides facilities for controlling access and update to Adabas files.
Adabas supports two classes of data access/update security: the first restricts user read and/or update requests on the basis of a whole file; the second restricts user access to individual records within a file.
Adabas files are security-protected if a file protection level greater than zero is assigned to the file. File protection levels are assigned separately for access (i.e. read) and update.
A user can access/update a security-protected file by entering a password with a permission level that is equal to or greater than the file protection level. Protection levels and password permission levels are assigned with the security utility ADASCR.
The file numbers that can be protected are limited by the block size of the ASSO1 container file. If the block size is 2KB, only files in the range 1 - 2047 can be protected (for 3KB the limit is 3071).
Security by Value extends the Adabas File Protection Level security by enabling a user to further define separate data access and update restrictions according to the content of one or more fields in a data record.
Security by Value criteria are defined by using the ADASCR security utility. Each password may include value criteria for up to 99 separate Adabas files.
Record level security can only be used with security-protected files.
If the Adabas users belong to different UNIX groups, you can restrict the Adabas access to databases assigned to this group.
An Adabas file can be security-protected by assigning an access protection level and/or an update protection level greater than zero to the file.
File protection levels range from 0 to 15, with 15 being the maximum level of protection. A protection level of 0 means that all users can access/update the file. A value of 15 prevents all users from accessing/updating the file.
All Adabas files that have no protection levels assigned have a default protection level of zero. All users can access and/or update such files.
| File | Protection Level Number | |
|---|---|---|
| Access | Update | |
| 10 | 7 | 11 |
| 11 | 2 | 2 |
| 12 | 4 | 4 |
Separate access and update levels for each Adabas file can be assigned for each password. Password permission levels can be assigned in the range from 0 to 14.
Password |
FILE 10 ACC/UPD |
FILE 11 ACC/UPD |
FILE 12 ACC/UPD |
|---|---|---|---|
| PASSWRD1 | 4/0 | 4/0 | 4/0 |
| PASSWRD2 | 2/2 | 2/2 | 2/2 |
| PASSWRD3 | 14/0 | 0/0 | 14/0 |
| PASSWRD4 | 14/14 | 14/14 | 14/14 |
| PASSWRD5 | 7/7 | 0/0 | 7/0 |
If the password access/update permission level is equal to or greater than the file access/update protection level, the password can be successfully used to access/update the file in question.
Using the examples for file protection levels and for password permission levels shown above,
PASSWRD1 can be used to access file 11 or file 12.
PASSWRD2 can be used to access/update file 11.
PASSWRD3 and PASSWRD5 can each be used to access file 10 or file 12.
PASSWRD4 can be used to access/update file 10, file 11 or file 12.
Separate access and update criteria for each Adabas file can be assigned for each password. Each value criterion consists of an Adabas search buffer and an associated value buffer.
The search and value buffers are constructed in the same manner as for regular Adabas search commands, including the use of non-descriptor fields and multiple value fields. However, soft-coupling and sub-, super-, hyper- and phonetic descriptor fields are not supported in Security by Value search criteria.
For further information on the syntax and construction of search buffers and value buffers, see the Command Reference Manual, Calling Adabas, Search and Value Buffers.
Value checking is performed only if data storage is either read or updated by the Adabas command.
The following table illustrates which criteria are tested for the various Adabas commands:
| Adabas Command | Security by Value Check Performed | |
|---|---|---|
| Test Criterion | Test Data | |
| A1 | Update | Before Image |
| E1 | Update | Before Image |
| L1 - L6 | Access | Before Image |
| L9 | (Access to index only, no value check performed) | |
| N1, N2 | Update | After Image |
| S1(*) | Access | Before Image |
Note:
* An S1 command with a valid format buffer is handled in the same
manner as if an S1 command followed by an L1 command with a given User ISN had
been issued.
Security by Value criteria are ignored if the associated security level of the requested file is zero.
Using the password entered by a user and the file-protection information defined for the file, Adabas checks whether the user is authorized to access/update a given Adabas file. If the file is not security-protected, Adabas ignores any password that is entered. The following describes Adabas security processing for read and update commands.
Adabas determines whether the file to be accessed or updated is security-protected. If there is no security protection, security processing stops.
If the file to be processed is security-protected, Adabas checks whether the password supplied is defined in the password table.
If the password is undefined or if no password has been supplied, response code 201 is returned.
If the password is defined but not valid for the file to be processed, response code 202 is returned.
If the password is valid for the file to be processed, Adabas checks the permission level associated with this password against the file's access or update protection level. Response code 200 is returned if the password's permission level is less than the file's protection level.
If the permission level is sufficient, the password is further checked for Security by Value criteria for the current file. If a search criterion has been defined for the supplied password, this is tested against either the before or after image of the data, depending on the Adabas command issued. If the Security by Value check is unsuccessful, response code 200 is returned, otherwise the user's request is finally granted and the Adabas command is processed.
The following is a summary of the response codes that may be returned by Adabas security processing:
| RESPONSE 200 | |
| Explanation |
Security violation detected. |
| User Action |
Supply the correct password. |
| RESPONSE 201 | |
| Explanation |
The password specified was not found. |
| User Action |
Supply the correct password. |
| RESPONSE 202 | |
| Explanation |
An attempt was made to use a file for which the user is not authorized. |
| User Action |
Supply the correct password. |
If an ET logic user receives the response codes 200 - 202, processing continues as if the user had exceeded the transaction time limit (see the TT parameter of ADANUC in the Utilities Manual for further information).
All Security by Value security violations cause response code 200 to be returned.
If the Adabas users belong to different UNIX groups, you can restrict the Adabas access to databases assigned to this group.
Note:
This feature is only available for UNIX, not for Windows
platforms.
Assume you have two UNIX groups called Production and Test. There are users belonging to the group Production, who should have access only to the production databases, and there are users belonging to the group Test, who should have access only to the test databases. Assume you have the following users for starting the database:
dbaprod belongs to the group Production and should start the production databases
dbatest belongs to the group Test and should start the test databases
The following is necessary to restrict the Adabas access to users of the group to which the databases belong:
You must use two different NET_WORK_IDs, even if you are not using Net-Work. Because Adabas does not know if a Net-Work server will be started later, Adabas creates a shared memory section common with Net-Work, a GDT (global database table). The permission for GDT access is restricted to the group to which the Adabas nucleus belongs. Therefore, starting a nucleus fails if the same GDT is accessed as used by another nucleus belonging to a different group.
You can use different GDTs if you start the nucleus with a different NET_WORK_ID because a separate GDT is created for each NET_WORK_ID. NET_WORK_ID is an environment variable, which must be set when the Adabas nucleus is started - two NET_WORK_IDs are considered to be equal if the first character is equal. If the environment variable NET_WORK_ID is not set, an empty NET_WORK_ID is used.
In this example, you could start the production databases after setting NET_WORK_ID to P, and the test databases after setting NET_WORK_ID to T.
The nucleus must be started with the parameter ADABAS_ACCESS=GROUP. Assume that you start in this example the Production databases with ADABAS_ACCESS=GROUP, but the Test databases with ADABAS=ACCESS=ALL (or without the parameter ADABAS_ACCESS). Then only the Production users can access the production databases, but all users can access the test databases.
Note:
If you are using Net-Work, it is also necessary to start different
Net-Work servers for different groups. You must take care to ensure that it is
not possible for users to access databases via Net-Work for which they have no
permissions.
