The purpose of terminal sets is to permit the effective administration of the set of terminals used for dialog access to a user ID. A terminal set contains a list of fully or partially qualified terminal names. Lists of terminal sets can be assigned positively or negatively to a user ID (cf command /MODIFY-LOGON-PROTECTION, operand TERMINAL-SET=..., or TERMINAL-SET=*EXCEPT(TERMINAL-SET=...), referred to below as positive list and negative list respectively). The terminals defined in a positive list have dialog access whereas the others do not. The terminals defined in a negative list have no access while the other terminals can perform access. The option of setting up negative lists should be carefully considered since under certain circumstances the number of terminals authorized to perform access may be unknown.
In addition, terminal sets can be associated with a guard of type STDAC. In this way, the effect of a terminal set can also be time-driven (for further details, see "Access to a user ID protected with terminal sets").
You can use the following commands to administer a terminal set:
CREATE-TERMINAL-SET | Create a terminal set |
MODIFY-TERMINAL-SET | Modify a terminal set |
DELETE-TERMINAL-SET | Delete a terminal set |
COPY-TERMINAL-SET | Copy a terminal set |
SHOW-TERMINAL-SET | Display a terminal set |
The following are authorized to perform administrative tasks:
global user administrators (owners of the privilege USER-ADMINISTRATION); they are authorized to administer all terminal sets
group administrators who possess at least the attribute MANAGE-MEMBERS. They are authorized to administer terminal sets belonging to the class GROUP or USER. The terminal sets must be assigned to the administrator’s group or its members.
There are 3 classes (name spaces) of terminal sets which differ in their owners:
USER
The specific user ID is the owner of this class of terminal set.
This terminal set can only be used by the user ID which owns it.
The terminal set is automatically deleted when the user ID is deleted.
GROUP
This type of terminal set is owned by a user group.
This terminal set can be used by all the members of the group which owns it. If a user ID ceases to be a member of the group then it also loses the right to use the terminal set. If such a user ID is no longer assigned to an authorized terminal, then it also has no further access in interactive mode.
The terminal set is automatically deleted when the group is deleted.
SYSTEM
The terminal set is public property.
Only the global user administrator is authorized to administer such terminal sets. Group administrators who possess the privilege MANAGE-MEMBERS can only copy or assign these terminal sets.
A terminal set is identified by its name and owner.
The example below presents four different terminal sets which all have the same name but different owners:
Name | Owner (SCOPE) |
TSET1 | *USER(USER-ID=USER1) |
TSET1 | *USER(USER-ID=USER2) |
TSET1 | *GROUP(GROUP-ID=GR1) |
TSET1 | *SYSTEM |
Protecting a user ID with terminal sets
A user ID with terminal sets is protected using the command /SET-LOGON-PROTECTION or /MODIFY-LOGON-PROTECTION.
When these commands are used, the access for a terminal or group of terminals can be explicitly permitted (positive list) or prohibited (negative list).
Access to a user ID protected with terminal sets
The following guidelines apply to access to a user ID which is protected with terminal sets:
The terminal sets are first checked to determine whether the current terminal name belongs to one of them (for further details on terminal names, see "Search for terminalnames"). The terminal sets are searched through in the following sequence:
classes: USER, GROUP, SYSTEM
within the classes: alphabetically on the terminal set names
If a user ID is protected by a positive list of terminal sets, then the following applies: If no terminal set containing the terminal name is found, there is no access. If one is found, a check is performed to determine whether this terminal set is associated with a guard of type STDAC. If it is not, access is permitted. If the terminal set is associated with a guard and the evaluation of the time conditions it contains returns the value ‘true’, access is permitted. If the result of the guard evaluation is ‘false’, there is no access.
Note
The result of a guard evaluation is always ‘false’ if the guard cannot be accessed or is of a type other than STDAC.
If a user ID is protected by a negative list of terminal sets, then the following applies: If no terminal set containing the terminal name is found, access is permitted. If one is found, a check is performed to determine whether this terminal set is associated with a guard. If it is not, access is not permitted. If the terminal set is associated with a guard and the evaluation of the time conditions it contains returns the value ‘true’, the negative list is considered to be effective and there is no access. If the result of the guard evaluation is ‘false’, the negative list is considered to be ineffective and access is permitted.
Note on the operand value TERMINAL-SET = *NO-PROTECTION or *NONE
The default value *NO-PROTECTION specifies that there is no protection via terminal sets.
The operand value *NONE assigns an empty list of terminal sets to the user ID. If all the terminal sets are withdrawn from the user ID, the empty list (of terminal sets) is again assigned to it. In this case, the user ID continues to be protected by terminal sets but no terminal set is found with the current terminal name. If the user ID is protected by a positive list, there is no access. If the user ID is protected by a negative list, all the terminals have access.
The following table presents the results of the access examination:
Matching name was found in: | Guard | |||
Not specified | Not | Conditions | Conditions | |
No terminal set (user ID | Access not permitted | |||
No terminal set (user ID | Access permitted | |||
Terminal set in positive list | Access | Access not | Access now | Access not now |
Terminal set in negative list | Access not | Access not | Access not now | Access now |
Search for terminal names
The name which is used to identify a terminal ,and which is searched for in the terminal sets depends on how access to the application $DIALOG is performed:
If the terminal has direct access to $DIALOG, this is identified by one pair of 8-byte names which designate the emulation and PC (STATION and PROC in the output from the /SHOW-JOB-STATUS command).
If there are intermediate applications (for example OMNIS), then there are two pairs of 8-byte names, with one pair designating the application name and the name of the computer on which the application is running (STATION and PROC), and the other the original terminal and name of the computer via which the application is operated (O_STAT and O_PROC). The latter pair is supplied by the application itself. It is not considered to be trusted unless the application name starts with the character $ and the examination is performed at the designated computer.
It is therefore easy to identify the access mode in question using the SHOW-JOB-STATUS command.
/show-job-status information=*all(terminal=*original)
TSN: 4L9W TYPE: 3 DIALOG1 NOW: 2018-04-03.171133
JOBNAME: PRI: 0 209
USERID: K98USER JCLASS: JCDSTD LOGON: 2018-04-03.1458
ACCNB: ACCXYZ CPU-MAX: 9000 CPU-USED:000007.0727
STATION: BT200683 PROC: D016ZE04
O_STAT: DSB17166 O_PROC: D016KR17
TID: 006001A8 UNP/Q#: 00/000
CMD: SHOW-JOB-STATUS
In the first case (direct access), in which there is only one name pair, no examination mode can be specified. The name pair must be entered in the terminal set (see the command MODIFY-TERMINAL-SET, operand TERMINAL-ENTRY=*ADD(...)).
In the second case (intermediate application, two name pairs), it is possible to choose between three examination modes:
CHECK-MODE=*STD:
If the application is trusted, a search is performed for the original terminal name/computer name. If it is not trusted, no access is permitted.CHECK-MODE=*NET-TERMINAL-NAME:
The original terminal/computer name pair is searched for in the terminal step as it was suppled by the application.CHECK-MODE=*APPLICATION-TERMINAL-NAME:
The application name/computer name pair is searched for in the terminal set.
Example of the examination of terminal names
Let us assume that the following 4 terminal entries have been defined
PROCESSOR | STATION | CHECK-MODE | |
1 | D016KR17 | DSB17166 | *STD |
2 | D016KR17 | DSB17166 | *NET-TERMINAL-NAME |
3 | D016KR17 | DSB17166 | *APPLICATION-TERMINAL-NAME |
4 | D016ZE04 | OMNISAPP | *APPLICATION-TERMINAL-NAME |
Access attempts are made by various terminals at computer D016ZE04. The table below shows the results of a check against the terminal entries in the last table. The names in the headings correspond to the field names output by the /SHOW-JOB-STATUS command. The result “Yes” means that the terminal entry matches the terminal from which the access attempt was made. “No” means that the terminal entry does not match. The figures refer to the reason for the result:
Intermediate | Terminal | Result of check against | |||||||
PROC | STATION | O_PROC | O_STAT | 1 | 2 | 3 | 4 | ||
No | D016KR17 | DSB17166 | - | - | Yes1 | Yes1 | Yes1 | No4 | |
Yes | D016ZE04 | OMNISAPP | D016KR17 | DSB17166 | No5 | Yes2 | No4 | Yes1 | |
Yes | D016ZE07 | $APPNAME | D016KR17 | DSB17166 | No6 | Yes2 | No4 | No4 | |
Yes | D016ZE04 | $APPNAME | D016KR17 | DSB17166 | Yes3 | Yes2 | No4 | No4 | |
Reasons: | |||||||||
1 | PROC/STATION is correct | ||||||||
2 | O_PROC/O_STAT is correct, PROC/STATION is irrelevant | ||||||||
3 | PROC/STATION is trusted and O_PROC/O_STAT is correct | ||||||||
4 | PROC/STATION is not correct | ||||||||
5 | PROC/STATION is not correct because STATION does not start with “$” | ||||||||
6 | PROC/STATION is not trusted because PROC is not the computer at which the access attempt |
Examples of system access control using terminal sets
Example 1
Access in interactive mode to the user ID USER0001 should only be possible via the terminal (processor: D016KR17, terminal: DSB17166). If access is performed via an application, the original terminal name should be checked.
Terminal set TERMSET1 is responsible for monitoring access.
|
(1) | Terminal set TERMSET1 is created. |
(2) | The terminal name is entered. The CHECK-MODE attribute is relevant for access via applications (e.g. OMNIS). The specification *NET-TERMINAL-NAME results in a lower level of protection since trustworthiness is not a precondition within the respective application itself. |
(3) | Terminal set TERMSET1 is assigned to user ID USER0001. |
(4) | Display of the complete terminal set. |
(5) | Display of job status after logon has been performed without an intermediate application. The pair (STATION,PROC) is checked. |
Example 2
Access in interactive mode to user ID USER0001 should only be permitted via PC PGTD1234. The PC itself is used by authorized personnel only during the working hours 08:00 to 18:00.
The terminal set TERMSET2 is to be exclusively assigned to user ID USER0001 and is to monitor access in conjunction with guard GUARD002.
|
(1) | Guard GUARD002 is created. |
(2) | The access condition for user ID USER0001 is declared in the guard. Access to user ID USER0001 is permitted daily from 08:00 to 18:00. |
(3) | Terminal set TERMSET1 is created in the name space of user ID USER0001. |
(4) | The PC PGTD1234 is entered in the terminal set as the permitted terminal device together with the guard which regulates access. The terminal name is irrelevant and is skipped by means of a wild card. |
(5) | The terminal set TERMSET2 is assigned to user ID USER0001. |
(6) | Display of complete terminal set. |
(7) | Display of job status after logon has been performed via OMNIS. The pair (O_STAT,O_PROC) is checked. |