Connections which have a generated authorization name no longer meet the strict security requirements of a system, because it is only possible to assign functional areas (i.e. a collection of authorization codes) to a device or to an authorized user program, and not to an individual person.
Such personalization is achieved by using connections with dynamic authorization names, because when a connection is made it is necessary to specify an operator ID (this corresponds to a user ID). Immediately after the “connection”, the user program has no authorizations, and can therefore only use operator functions which require no authorization, and commands which have the authorization code @. Not until the REQUEST-OPERATOR-ROLE command is issued (authorization code @) can authorizations be applied for, and their assignment is subject to an OPERID-related check. An operator role corresponds to a functional area, and is a set of authorization codes compiled by systems support, in which any number and combination from a total of 40 authorizations may be specified. An authorized user program may apply for several operator roles. The logical sum of the operator roles then produces the authorization profile of an authorized user program.
The definition of operator roles by systems support makes it possible to allocate operator functions to individual persons and to assign them to authorized user programs.
Setting up the connection for a dynamic authorization name
The connection for an authorized application with a dynamic authorization name is always set up in several steps. Most are optional, depending on the specifications made in the connection message and how the used operator ID is protected.
$CONSOLE (system task UCON) cannot check whether $CONSOLE or @CONSOLE, specified in the incoming connection request, corresponds to the reality ($CONSOLE for the data display terminal as the terminal user and @CONSOLE for a program as the terminal user) since these connection requests are always submitted by a mediator program (e.g. OMNIS).
Systems support should ensure that only mediator programs which can check that the input is correct (first character either “$” or “@”) are used. It can restrict access to BS2000 for selected IDs exclusively to the data display terminal (see the SET-LOGON-PROTECTION command).
Step 1: request connection
The authorized user program initially sends a connection request to $CONSOLE on the desired system with the following structure (x=$ or x=@, depending on the type of program connection, see also section "Format of the connection message for dynamic authorization names"):
NAME=xCONSOLE[,OPERID=<name>][,PASSWORD=<password>][,PROTVERS=V<integer>]The connection is accepted provisionally if the following criteria are satisfied:
not all of the dynamic authorization names are in use
the logon is permitted by the system parameter NBBAPRIV
The provisional acceptance is accompanied by a text, from which the protocol version (PROTVERS) accepted by $CONSOLE (UCON), and the BS2000 version are to be taken. If the protocol version requested is greater than the highest version which is supported by $CONSOLE, the accompanying text contains the maximum value that UCON can accept.
Structure of the accompanying text:
00 - 18 DC
C'CONNECTION ACCEPTED'
19 bytes
19 DC
C' ' (Blank)
1 byte
20 - 21 DC
C'nn' (Protocol version number)
2 bytes
22 DC
C',' (Comma)
1 byte
23 - 26 DC
C'nn.n' (BS2000 version number)
4 bytes
For BS2000 OSD/BC V11.0 the BS2000 version number output is C'20.0'.
Irrespective of the version of the protocol which was requested in the connection request, from this point on until the connection is finally accepted or rejected, all messages in both directions will be given a header. The protocol must be strictly adhered to; any unexpected inputs during the logging on dialog will lead to rejection of the connection attempt.
Step 2: OPR-LOGON-REQUEST
If the OPERID operand has not been specified, it will be requested by the system in a dialog with the
“PLEASE LOGON”message.
The authorized user program must now respond with the following message (the ISP formatLOGON <name>,,<password>is permissible):
SET-LOGON-PARAMETERS USER-ID=<name>[,PASSWORD=<password>]The password specified in SET-LOGON-PARAMETERS is used for subsequent checks. Any password which was specified in the connection message will always be ignored if a retrospective SET-LOGON-PARAMETERS command was requested.
Step 3: protection criteria check
Using the information received up to this point, the protection criteria stored by the system in the user catalog for the operator ID, is now requested.
The connection is shut down if the authorization data check shows that a connection in the specified mode (OPERATOR-ACCESS-TERMINAL or OPERATOR-ACCESS-PROGRAM in the user catalog) is not allowed for this operator ID.
Step 4 is skipped if the authorization data check shows that the connection is not protected by a password.
Step 4: request for password
If the password has not been input, it is requested by the system with
“PLEASE ENTER PASSWORD”.
The authorized user program must now respond with the password. The input is hidden under OMNIS.Step 5: check of access authorization
After the authorized user program has passed all necessary data to the system, it must still await confirmation of the connection to the system before it can start normal message communications, in conformity with the version of the protocol specified in the connection request.
The system checks the connection data and makes a final acceptance of the connection if the specified password is correct or no password is required and OPERID and PASSWORD in the user catalog entry agree (if the OPERID has to be authenticated against a password).
The confirmation contains the following text to be output on the data display terminal:
CONNECTION REQUEST ACCEPTED, APPLICATION NAME = @xxx
Initially, the connected authorized user program can only enter a few commands which do not merit protection (code @). In order to execute operator functions, the program must now request one or more operator roles with a REQUEST-OPERATOR-ROLE command.
Format of the connection message for dynamic authorization names
[NAME=]xCONSOLE [,[OPERID=]name]
[,[PASSWORD=]C'password 1..8']
[,[PROTVERS=]Vn]
[,[DISCON=]{YES/NO}]
The connection request can also be made without a password.
xCONSOLE
Identifies the type of program connection in a secure system (see the SET-LOGON-PROTECTION command in the “SECOS” manual “Access Control”[46]). For x either “$” or “@” can be used:
$CONSOLE
Indicates that the authorized user program is operating interactively with a person. The access authorization is checked against the definitions set with the OPERATOR-ACCESS-TERM operand of SET/MODIFY-LOGON-PROTECTION.
@CONSOLE
Indicates that the authorized user program is operating in batch mode. The access authorization is checked against the definitions set with the OPERATOR-ACCESS-PROGRAM, operand of SET/MODIFY-LOGON-PROTECTION.
OPERID=<name>
An operator identification name. An operator identification is a user ID for an operator. Initially, there is no functional difference between this and a conventional user ID. Only when a SET-LOGON-PROTECTION command has been used to assign operator authorizations to a user ID does it become meaningful to refer to an OPERATOR Identification.
PASSWORD=C'<password 1..8>'
As for any user ID, a password can be specified for an operator ID. The password entered for the operator ID in the user catalog must be specified.
A hexadecimal password is not permitted. The password may be a maximum of 8 characters in length.
PROTVERS=Vn
Designates the version number of the interface between the application and $CONSOLE (n = 00, 01, 02). Each version number corresponds to a unique communications protocol, which is supported and observed by $CONSOLE.
The default value is 00. In this case, messages transmitted in either direction between the system and authorized user programs have no headers.
Under version 01, the messages received from the system by an authorized user program include a header. For messages from the message file, output by the MSG7 or MSG7X macro, the transmitted message has a trailer appended, containing a “data-oriented” mapping of the message, for a programmable evaluation. The data format of the header is defined by the NBMHE macro, that of the trailer by the NBMAP macro (see "NBMHE macro" in section "Message formats" and "NBMAP macro" in section "Message formats"). Messages transmitted from an authorized user program to the system are, as for protocol version 00, sent without headers.
Under version 02, messages transmitted in either direction between the system and authorized user programs have headers. This enables authorized user programs to identify messages as the results of commands or supplementary information, and the system to report the end of command processing.
If the PROTVERS operand is missing from the connection message, the default value 00 is set. If too high a value is specified in PROTVERS, the highest version operated by the system is entered in the text accompanying the connection acceptance. The version number of the interface requested can therefore be set. If the authorized user program does not match the version number set, it can clear the connection.
DISCON
Defines how the system reacts if the authorized user program has such a backlog of messages to receive that the time defined by the system parameter NBRCSCK[N] is exceeded.
DISCON=YES
Default: the system clears the connection to the authorized user program.
DISCON=NO
The authorized user program is not disconnected. Instead of this, all messages waiting to be sent to the authorized user program are deleted and replaced with a single NBR0601 message.
NBR0601 SOME MESSAGES DISCARDED SINCE THE DESTINATION APPLICATION DID NOT
RECEIVE THEM JUST IN TIME
Connection cleardown
To terminate the $CONSOLE application and release the connection, the EXIT-JOB command (in conjunction with NBCONOPI=Y) is offered. This also implicitly implements the function of RELEASE-OPERATOR-ROLE OPERATOR-ROLE=*ALL and thus the release of all authorization codes.