Horizon network security
Overview
A distributed transaction consists of at least two parts: the part that requests a remote service (the client), and the part that services the request (the server). This section describes the security concerns of a Horizon network from the point of view of the server and then of the client.
Terminology
Server and client systems are Model 204 ONLINEs that contain application programs that converse with each other. The client program usually communicates directly with a human end user at a terminal. The server program has no access to the terminal. All its communication to the end user must pass through the client program. In addition, the server program is not accessible by terminals attached to the server system, because the service thread is a non-terminal thread.
A system may be a client system or a server system or both.
Contents
Security issues for Horizon are divided into the following three areas:
-
Server system access.
Managing the use of server system resources by remote and local users. This is discussed in Managing access to a server system.
-
Client system use.
Controlling a client system's local users' access to server systems. This is discussed in Controlling users on a client system.
-
Network node name use.
Protecting network node names from unauthorized use (see Protecting network node names).
This topic provides a description of the features that Model 204 offers to help the system manager control these security issues. A series of examples of different security schemes concludes the topic.
Managing access to a server system
The following issues are of concern to the manager of a server system:
- Controlling which remote client systems may make requests of the server system. This is discussed in Controlling remote client system access to the server.
- Specifying which individual users from a given client system may use the server system, and which server programs they may use. This is discussed in Controlling individual remote users.
- Protecting the file which contains the service transaction program. This is discussed in Protecting procedure files.
The figure "Lines of defense for a server system" shows how these issues represent layers of protection for the server system, and how access is controlled. Refer to it during the discussion of access to a server system.
Lines of Defense for a Server System
Controlling remote client system access to the server
The system manager of a server system controls access to the server system as a whole and to each of its resources individually. This control is exercised through the DEFINE PROCESSGROUP and DEFINE PROCESS commands that precede any use of the Horizon facility.
Controlling access to a server system
For a client system to establish an SNA session with a Model 204 server, the client's network node name must be coded in the REMOTEID parameter of a server's DEFINE PROCESSGROUP command. Since this command requires system manager privileges, a given client system must be specifically authorized by a server's system manager to gain access to the server.
For example, referring to the figure "Logical network view from New York and Boston" in Network management, the following abbreviated DEFINE PROCESSGROUP command allows sessions with the network node M204HQ:
DEFINE PROCESSGROUP PGRP1 WITH REMOTEID=M204HQ...
Controlling access to a server program
For a given server program (that is, application subsystem or procedure) to be accessible from any client system, the server system manager must include the name of a processgroup that defines that client system in the FROM parameter of the server program's process definition. The system manager is thus required to tell Model 204 explicitly which nodes in the network may access any server program.
For example, referring to the figure "Logical network view from New York and Boston" in Network management, the following abbreviated DEFINE PROCESS command allows access to the server program WSALES from the client system M204HQ (which is defined in processgroup PGRP1):
DEFINE PROCESS WSALES FROM=PGRP1...
Controlling individual remote users
Model 204 login and Application Subsystem security processing are the principal means by which a system manager controls remote user access to service resources. This section first describes the layers of login processing and possible security options, and then describes Application Subsystem security options.
Login processing
For an end user, the first level of security in Model 204 is login processing. The typical terminal-attached end user presents a password at login time. The system uses the password to verify the user's ID. The ID then can be reliably used to assign operational privileges and to grant access to various resources. These assignments are made according to rules contained in Model 204 Application Subsystem security and external security packages.
Login processing for a client user who logs into a Model 204 system to process part of a distributed transaction differs from that for a typical terminal end-user in the following ways:
- Absence of command level access
- Problematic password use
Access to command level
A successfully logged-in terminal thread accesses a Model 204 system at "command level" (the > prompt) unless the AUTOSYS parameter is specified for the thread. (The AUTOSYS parameter automatically places the user in a subsystem after login to Model 204.) The terminal end user is then permitted certain ad hoc capabilities: to issue certain Model 204 commands, compose and run temporary SOUL Requests, open files, send messages to other users, and so on.
A successfully logged-in Horizon client user, however, is passed directly into a "canned" application: the process to which the user is connecting (which must be predefined by the server's system manager). Unless that process (server application) is specifically designed to build and execute ad-hoc requests from the client program, the client end user has no ad-hoc capability, because the server thread is never at command level.
To change the server application's behavior, the end user must be able to log into the server system on a terminal thread and change the server application program.
Password problems
At login time, a terminal end user typically supplies a password at the terminal and is admitted to Model 204 with the appropriate privileges. Supplying a password may not be as easy for a client program, however: when processing a transaction distributed over many server systems, each system involved may require a login from the client. Prompting the end user repeatedly for a password is cumbersome and needlessly exposes the end user to underlying network communication activity. Having the required passwords in a file may be a security exposure.
To resolve this password problem, Horizon login processing introduces options ("trusted" users and "guest" users) for logging in client users that do not present passwords. These options are described in the discussion of Horizon login options that follows.
Login options
In this section, the decisions made during Horizon login processing, as depicted in the branches of the login tree in the figure "Login security processing," are described following the figure.
The following figure is a hierarchical representation of the various Horizon security options that affect login for a client user trying to run a server program.
<IMG SRC="CHAP4-3.gif" USEMAP="#CHAP4-3">
Login security processing
Login required
When the SYSOPT (system options) parameter X'10' bit is on, login is required for any user of the ONLINE. Successful login passes the client user to the server's Application Subsystem security checking, which is reviewed in Application Subsystem security.
For details on security, see Storing security information (CCASTAT).
A failure in login processing on the service online system causes the client's OPEN PROCESS request to fail, rejected by the server system.
Login processing first checks for a valid user ID.
USERID
- USERID absent
If USERID is absent from the incoming OPEN PROCESS request and login is required, login fails.
- USERID present
If USERID is present, processing proceeds to check for a password.
PASSWORD
-
PASSWORD present
If PASSWORD is present in the incoming request, Model 204 uses it to validate the login.
- PASSWORD valid
If the password is valid, login succeeds and the user is passed to Application Subsystem security.
- PASSWORD invalid
If the password is not valid, login fails.
- PASSWORD absent
If the PASSWORD is absent, processing proceeds to check further options.
Trusted LU
If LOGIN=TRUST is specified on the DEFINE PROCESSGROUP command used to define the client to the server, the server system does not require a password to log the user in. The server's system manager uses this option based on the belief that the client node reliably verifies that the requesting user is valid.
Using this option makes it unnecessary to store and pass login passwords throughout the network when processing a distributed transaction. LOGIN=TRUST must be coded on both the DEFINE PROCESSGROUP command defining the server to the client and the one defining the client to the server.
The effect of LOGIN in the Horizon login process is as follows:
- LOGIN=NOTRUST
The client system is not DEFINEd as trusted by the server, and login fails.
-
LOGIN=TRUST
The server system simply accepts the user ID passed in the request from the client system without requiring a password. Processing proceeds to the known user test.
User known
If the client system is trusted, Model 204 attempts to log the user in without a password. A "known" user is one whose USERID value is defined in either the server's password table (CCASTAT) or in the external security package CA-ACF2. (For the security packages Security Server (formerly RACF) and CA-Top Secret, see the Note below.) Login processing of the USERID value on an incoming request proceeds as follows:
- USERID known
If the requesting USERID value is known, login succeeds and user privileges are as defined in CCASTAT or CA-ACF2. The user is passed to Application Subsystem security.
- USERID unknown
If the requesting USERID value is not known, login processing proceeds to the guest user test.
Note: USERIDs defined to Security Server or to CA-Top Secret are always considered unknown. If a USERID value is not defined in CCASTAT but is defined in Security Server or CA-Top Secret, the user is considered unknown and login processing proceeds to the guest user test.
Login not required
When the SYSOPT X'10' bit is off, login is not required. An incoming conversation request can proceed even if no user ID is present on the client request.
When login is not required, the outcome of Horizon login processing depends on whether a user ID is present:
- USERID present
The login is processed just as if login were required:
- If login requirements are met, Horizon assigns the user the user ID passed in the request. The user is passed to Application Subsystem security checking.
- If login requirements are not met, login fails and no conversation is allowed.
- USERID not present
Horizon assigns the user an ID of "NO USERID," an account of "NO ACCOUNT," and Superuser privileges.
When login is not required, the resources of the server ONLINE are still protected. With a user ID of NO USERID, the client user cannot be admitted to private application subsystems or to the restricted classes of semipublic subsystems. The user may not open protected files without a valid password and may not issue restricted commands.
A user of a non-Model 204 client system whose LU 6.2 interface does not support security parameters can only connect to a service ONLINE that does not require login.
Application Subsystem security
After login security processing, the following kinds of client users pass to Application Subsystem security processing.
Client users...
- ...with valid user IDs and passwords
- ...with known user IDs and no passwords but from trusted LUs
- ...without known user IDs but who are "guests" from trusted LUs
- ...with user IDs but for whom login processing was not required
Client users must pass through Application Subsystem security before they can execute any service transaction. Based on the user ID and the type of the subsystem, Application Subsystem security decides:
- Who is allowed to enter a given subsystem
- What privileges are granted upon entry
- What kind of access to subsystem-owned files is granted
This section contains a brief summary of how the subsystem handles these three security concerns. For a more thorough description of application subsystems, see System requirements for application subsystems.
Controlling who is allowed in
Subsystems can be public, semipublic, or private. They differ in how they treat attempts to enter the subsystem.
- A public subsystem permits all users to enter and gives all users the same level of privileges.
- A semipublic subsystem permits access to all users. A user defined to the subsystem gets the privileges associated with that user class (SCLASS). Undefined users get the privileges associated with the default SCLASS.
- A private subsystem admits only users who are defined to it.
How privileges are assigned
Individual privileges held at entry to the subsystem can be overridden by the user's SCLASS assignment. The system manager may assign different privileges for each SCLASS.
The privileges set in the SCLASS definition are equivalent to the user privileges ordinarily granted upon successful login to Model 204: the power to create files, issue certain privileged commands, change passwords, or access secured records.
For more information about these privileges, see System requirements for application subsystems.
The SCLASS may also define the account name the user is assigned while in the subsystem, and may also define the record security key for the user.
This assignment of privileges, account name, and record security key lasts only while the user is in the subsystem in question. If the user transfers to another subsystem, the new subsystem determines privileges, account, and record security.
How access to subsystem files is assigned
SCLASS definition also controls what files a user may open and what file privileges are granted per file.
Protecting Procedure Files
The service program resides in a procedure file in the server ONLINE. This file can be protected from access by end users on the server system by making the file semipublic or private, that is, by requiring a password. The file is opened automatically upon entry to the server subsystem, making a password unnecessary for client system users.
Controlling Users on a Client System
This section discusses the following issues of concern to the manager of a client system:
- Specifying which remote server systems may be accessed from the local system
- Specifying which remote server definitions are available for ad hoc use and which are to be restricted to application subsystems
- Controlling the ways in which individual users are allowed to identify themselves to a server system
Defining remote server systems
Using the DEFINE PROCESSGROUP and DEFINE PROCESS commands, the system manager of the client system defines the remote server systems and programs with which the client can communicate.
- DEFINE PROCESSGROUP
Just as the server system requires that each remote client system be defined to it in a DEFINE PROCESSGROUP command, the client system requires that any server system to which it passes a request be defined the same way: through the REMOTEID parameter.
Each remote service must be defined in a DEFINE PROCESS command. The DESTINATION parameter specifies to which service systems an OPEN PROCESS request for this transaction may be directed.
Restricting access to remote server systems
A distributed application can be designed in such a way that the server side of the application is responsible for all checking to make sure that its client is authorized to issue incoming requests. However, having the server prevent malicious or incorrect client programs from compromising it may be inconvenient. It is often easier for the server program to assume that it is conversing with a correctly debugged, trustworthy client. This assumption implies two requirements:
- The code of the client program is protected from unauthorized modification.
- An unauthorized program is prevented from "posing" as the client.
Restricting client programs to application subsystems achieves this protection.
An application subsystem provides a secure environment in which to package and run the client program, thus providing the first protection above. Access to a client program can be limited to predefined users. The behavior of the client program can be further restricted by the definition of the SCLASS to which the end user is assigned. Unauthorized end users are prevented from changing either the client or server.
The second protection listed above is provided by blocking the access of non-subsystem clients. In SOUL, a program establishes itself as a client by issuing the OPEN PROCESS statement to initiate a conversation with a server. To block an OPEN PROCESS statement issued by a client running outside the application subsystem environment, the client system manager can use the RESTRICT parameter of the DEFINE PROCESS command, as follows:
RESTRICT=APSY
When RESTRICT=APSY is coded, end users outside the subsystem cannot run their own copy of a client program. They must use the subsystem's copy.
Controlling user identification to a remote server system
A client program can pass to a server system a user ID, password, and account (or profile) other than the current value of these items by supplying new values in the USERID, PASSWORD, and ACCOUNT (or PROFILE) parameters of the OPEN PROCESS statement.
To control any such client program changing of USERID and ACCOUNT (or PROFILE), the system manager of the client system can choose one of the following three options for the DEFINE PROCESS command UIDSOURCE, ACCTSOURCE, or PROFSOURCE parameters:
- CURRENT
- OPEN
- NONE
Using the CURRENT option with UIDSOURCE and ACCTSOURCE (or PROFSOURCE)
If CURRENT is specified, the client program cannot change the user ID or account number (or profile) that the server sees by coding them on the OPEN PROCESS statement. If these parameters appear on the OPEN PROCESS statement, the OPEN fails. The client's OPEN PROCESS passes to the server only the user ID and account with which the user is currently logged in.
This option is designed to be used in combination with the LOGIN=TRUST option of DEFINE PROCESSGROUP. Even if the PROCESS definition specifies UIDSOURCE=CURRENT, the OPEN PROCESS statement may contain a PASSWORD parameter (unless the partner is a non-Model 204 program); but if the conversation is initiated with a TRUSTed server, the password is not needed.
Using the OPEN option with UIDSOURCE and ACCTSOURCE (or PROFSOURCE)
OPEN allows the client program to change the user ID or account that the server sees. The client may use values other than those currently logged in to the server by specifying them on the OPEN PROCESS statement.
If the client specifies the USERID parameter on OPEN PROCESS, the PASSWORD parameter must also be supplied. ACCOUNT (or PROFILE) may be changed without supplying PASSWORD. If a program omits the USERID or ACCOUNT (or PROFILE) parameter, the user's current user ID or account is passed.
Using the NONE option with UIDSOURCE and ACCTSOURCE (or PROFSOURCE)
The NONE option suppresses all security information in the OPEN request. It is useful when the server system does not require login. It may be required in future Horizon implementations if the server system is a non-Model 204 system that does not accept security parameters from clients. Such a system may reject an OPEN request that includes security parameters.
The following table displays the effects of the UIDSOURCE and ACCTSOURCE options, depending on what the OPEN PROCESS contains. The results in the table are the same if PROFILE and PROFSOURCE are substituted for ACCOUNT and ACCTSOURCE, since they are synonyms.
Selection of User ID and Account Number
| Value of UIDSOURCE and ACCTSOURCE: | ||||
|---|---|---|---|---|
| CURRENT | OPEN | NONE | ||
| USERID or ACCOUNT coded on OPEN PROCESS statement: | Yes | Open fails | Taken from OPEN PROCESS | OPEN fails |
| No | Current | Current | None | |
Protecting Network Node Names
The system manager authorizes each network node that a given Model 204 system may communicate with by specifying its name in the REMOTEID parameter of a DEFINE PROCESSGROUP command. Certain options of the DEFINE PROCESSGROUP command (LOGIN=TRUST and GUESTUSER=ACCEPT) grant special status to the node named in the REMOTEID parameter. To confidently designate a partner system as trusted, a system manager must be assured of the following:
- The only user of that node name is the system that the user is authorizing.
- Individuals cannot bring up their own unauthorized system that identifies itself to the network using an authorized node name.
Using SNA Communications Server password protection
SNA Communications Server (formerly VTAM)'s APPL statement, which defines a network node name, provides an option to restrict use of that name. The PRTCT parameter, when coded, contains a password that must be supplied when the SNA Communications Server ACB is opened. This feature can be used to insure that certain network node names are used only by authorized systems.
If PRTCT is coded on the APPL definition, the PSWD parameter must be included in the DEFINE LINK command. PSWD causes the OPEN LINK command to prompt for a password. If the password given does not match the one which appears in the APPL PRTCT parameter, the OPEN LINK command fails.
For more information
Coding the SNA Communications Server APPL definition is described further in Defining the Network to SNA Communications Server. The DEFINE LINK command is described in Defining a Horizon network.
Security Design Examples
Horizon was designed to place responsibility for understanding network topology and security in the hands of the system manager and to shield the application programmer from these considerations. This section contains a series of security design examples that increase in complexity and show some of the range of possible security options. Starting with a very simple design, which uses a minimum of features, new options are added as they are needed to satisfy the given security needs of each example.
Six security design examples are provided. In each example, security features that are new or changed from the previous example are noted. The following table identifies the example number and its features:
| Example | New or highlighted feature |
|---|---|
| 1. | No server or client security: default security parameters. |
| 2. | Server has login security protection. |
| 3. | Server trusts client; server-client link is SNA Communications Server-password protected; client system is login protected. |
| 4. | Server trusts client; client programs can only be application subsystems. |
| 5. | Two trusted client processes: one restricted to application subsystems and one, unrestricted, for ad hoc requests. Server can differentiate between the two processes. |
| 6. | Two trusted client processes; application subsystem security in effect for server |
Example 1: Login Not Required on Server
By default, no security options apply to a Horizon conversation. The server system must be configured with the SYSOPT=X'10' bit off (login not required) to permit a client (who is not passing a user ID) to OPEN a PROCESS for which no security attributes have been specified.
This section contains displays of sample client and server coding for this example, followed by notation of the security aspects featured. The client and server DEFINE commands and SOUL requests use the default security parameters, which are coded explicitly and accompanied by comments. Most non-security related parameters are omitted.
Coding for client
| Client Network Definition | Comments |
|---|---|
|
DEFINE LINK LINKCLI WITH - LOCALID=M204HQ - NOPSWD |
No LINK password prompt |
|
DEFINE PROCESSGROUP PGCLI WITH- LINK=LINKCLI - REMOTEID=M204BO - LOGIN=NOTRUST - GUESTUSER=REJECT |
Login of unknown user fails |
|
DEFINE PROCESS WKSALES WITH - DESTINATION=PGCLI - PARTNER=WSALES - UIDSOURCE=NONE - ACCTSOURCE=NONE - RESTRICT=NONE |
Send no user ID in OPEN request |
| Client Conversation | Comments |
|---|---|
|
BEGIN OPEN PROCESS WKSALES . . converse . . CLOSE PROCESS WKSALES END |
No USERID, PASSWORD, or ACCOUNT |
Coding for server
| Server Network Definition | Comments |
|---|---|
SYSOPT=X'nn' (X'10' bit off) |
Login not required |
|
DEFINE LINK LINKSRV WITH - LOCALID=M204BO - NOPSWD DEFINE PROCESSGROUP SALES WITH - LINK=LINKSERV - REMOTEID=M204HQ - LOGIN=NOTRUST GUESTUSER=REJECT DEFINE PROCESS WSALES WITH - FROM=SALES - SUBSYSTEM=WKS |
No LINK password prompt
Logon of unknown user fails
|
| Server Conversation |
|---|
|
BEGIN OPEN PROCESS internalname ACCEPT . . converse . . CLOSE PROCESS internalname END |
Notes:
-
The server system is not necessarily unsecured:
- The system can be configured solely for use by client users, so that the files are protected by Application Subsystem security.
- The system manager can password protect the ONLINE's files.
- The ONLINE system may be configured with no terminal threads. The system manager may define only server threads (IODEV=27).
- The only source authorized as a client user of the WKS subsystem is Headquarters (M204HQ).
- The WKS subsystem must be either semipublic or public: the client user is sending no security parameters and therefore enters the subsystem with a user ID of NO USERID and an ACCOUNT value of NO ACCOUNT. A private subsystem requires a user ID other than NO USERID.
Example 2: Login Required on Server
In this example, the system manager of the server system from the previous example adds an end user application to that system, as well as some public files which end users can open at will.
To control which users can enter the server ONLINE, the server system manager turns on X'10' of the SYSOPT parameter, causing the system to require login. The system manager of the server system informs the system manager of the client system at Headquarters that client Horizon requests fail without a user ID.
User IDs presented are validated if they are defined in the server's CCASTAT file or in an external security database such as ACF2.
In this and following examples, the defaulted values are removed. Changes to the example configurations are indicated by two plus signs (++) to the left of the line.
Coding for client
| Client Network Definition | Comments | |
|---|---|---|
|
|
DEFINE LINK LINK1 WITH - LOCALID=M204HQ DEFINE PROCESSGROUP PGRP1 WITH - LINK=LINK1 - REMOTEID=M204BO DEFINE PROCESS WKSALES WITH - DESTINATION=PGRP1 - PARTNER=WSALES - UIDSOURCE=OPEN |
|
| Client Conversation | Comments | |
|---|---|---|
|
BEGIN %UID=$READ('ENTER USERID - %PSWD=$READ('ENTER PASSWORD') OPEN PROCESS WKSALES WITH - USERID %UID - PASSWORD %PSWD . . converse . . CLOSE PROCESS WKSALES END |
|
Coding for server
| Server Network Definition | Comments | |
|---|---|---|
|
++ |
SYSOPT=X'nn' (X'10' bit on) |
Login required |
|
DEFINE LINK LINKSRV WITH - LOCALID=M204BO - DEFINE PROCESSGROUP SALES WITH - LINK=LINKSRV - REMOTEID=M204HQ - DEFINE PROCESS WSALES WITH - FROM=SALES - SUBSYSTEM=WKS |
|
|
| Server Conversation |
|---|
|
BEGIN OPEN PROCESS internalname ACCEPT . . converse . . CLOSE PROCESS internalname END |
Notes:
- The only parameters changed in this example are SYSOPT on the server side and UIDSOURCE on the client side.
- The USERID and PASSWORD parameters are added to OPEN PROCESS on the client side to allow the Horizon request to successfully log in to the server system.
- Each user of the client request is prompted for a user ID and password to be passed to the server system.
- The server's system manager must now define each authorized client user from M204HQ, as well as each end user who uses his ONLINE, in either the CCASTAT file or an external security database, for example, ACF2.
Example 3: Trusting the Client
Each time that an end user on the client ONLINE wants to run the Horizon request, the user must enter a user ID and password to access the server node. To relieve this burden, the application is changed so that the client system is trusted. A client user is prompted for a password only upon logging in to the client system.
Coding for client
| Client Network Definition | Comments | |
|---|---|---|
|
|
DEFINE LINK LINKCLI WITH - LOCALID=M204HQ - PSWD DEFINE PROCESSGROUP PGCLI WITH - LINK=LINKCLI - REMOTEID=M204BO - LOGIN=TRUST DEFINE PROCESS WKSALES WITH - DESTINATION=PGCLI - PARTNER=WSALES - UIDSOURCE=CURRENT - |
|
| Client Conversation | Comments | |
|---|---|---|
|
|
BEGIN OPEN PROCESS WKSALES . . converse . . CLOSE PROCESS WKSALES END |
No user ID or password need be coded anymore. |
Coding for server
| Server Network Definition | Comments | |
|---|---|---|
|
|
DEFINE LINK LINKSRV WITH - LOCALID=M204BO - DEFINE PROCESSGROUP SALES WITH - LINK=LINKSRV - REMOTEID=M204HQ - LOGIN=TRUST DEFINE PROCESS WSALES WITH - FROM=SALES - SUBSYSTEM=WKS |
|
| Server Conversation |
|---|
|
BEGIN OPEN PROCESS internalname ACCEPT . . converse . . CLOSE PROCESS internalname END |
Notes:
- Both the client and server processgroup definitions are changed from LOGIN=NOTRUST to LOGIN=TRUST. This attribute must be the same on both partners' processgroup definitions for Horizon to work.
- The PSWD parameter is added to the LINK definition. Since these partners are to TRUST each other, they must be protected from a situation in which an impostor opens a link using one of their LOCALID names. Specifying PSWD causes the password prompt to be displayed at OPEN LINK time; however, password verification is initiated by adding the PRTCT parameter to the SNA Communications Server APPL definition for each LOCALID.
Note that this (SNA Communications Server) password is completely unrelated to any login password and has nothing to do with the CCASTAT file.
- The client process definition has UIDSOURCE=CURRENT, prohibiting the SOUL program from specifying its own user ID on OPEN PROCESS.
- The client system passes (without a password) the end user's currently logged in user ID to the server system. Since the client system is another Model 204 system, the server's system manager can trust that the client system verified the end user's password before allowing that user to operate with that user ID.
This is true even if login is not required on the client system: if the end user does not log in or if their login fails, they proceed with a user ID of NO USERID.
- The end user no longer has to pass a password for a conversation with the M204BO system, and may not even be aware that the application does any underlying communication.
- Any number of trusted systems can be defined this way.
Example 4: Protecting the Client Process Definition
The sample application is revised so that the service program now performs some updates. (Note that only one node is updated by a given transaction. As discussed in Horizon User Language (SOUL) sample programs, a two-node update can cause problems at recovery time.) An incorrectly written client request that OPENs the PROCESS may cause data corruption on the server system. To prevent ad hoc client requests from using the process definition, the client system manager makes the following adjustment.
Coding for client
| Client Network Definition | Comments | |
|---|---|---|
|
|
DEFINE LINK LINKCLI WITH - LOCALID=M204HQ - DEFINE PROCESSGROUP PGCLI WITH - LINK=LINKCLI - REMOTEID=M204BO - LOGIN=TRUST DEFINE PROCESS WKSALES WITH - DESTINATION=PGCLI - PARTNER=WSALES - UIDSOURCE=CURRENT - RESTRICT=ASPY |
|
| Client Conversation | Comments |
|---|---|
|
BEGIN OPEN PROCESS WKSALES . . converse . . CLOSE PROCESS WKSALES END |
|
Coding for server
| Server Network Definition | Comments |
|---|---|
|
SYSOPT=X'nn' (X'10' bit on) |
Login required |
|
DEFINE LINK LINKSRV WITH - LOCALID=M204BO - DEFINE PROCESSGROUP SALES WITH - LINK=LINKSRV - REMOTEID=M204HQ - LOGIN TRUST DEFINE PROCESS WSALES WITH - FROM=SALES - SUBSYSTEM=WKS |
|
| Server Conversation |
|---|
|
BEGIN OPEN PROCESS internalname ACCEPT . . converse . . CLOSE PROCESS internalname END |
Notes: There is only one difference: RESTRICT=APSY has been added to the process definition on the client side.
Example 5: Two Different Process Definitions: Inquiry and Update
Some users on the client system require ad hoc access to the process definition to do inquiries. The solution is to define two separate processes: one for inquiry-only work, accessible to ad hoc requests, and another for updates, which may only be used by a canned application subsystem.
Coding for client
| Client Network Definition | Comments | |
|---|---|---|
|
|
DEFINE LINK LINKCLI WITH - LOCALID=M204HQ DEFINE PROCESSGROUP PGCLI WITH - LINK=LINKCLI - REMOTEID=M204BO - LOGIN=TRUST DEFINE PROCESS WKSALESU WITH - DESTINATION=PGCLI - PARTNER=WSALESU - UIDSOURCE=CURRENT - RESTRICT=APSY DEFINE PROCESS WKSALES WITH - DESTINATION=PGCLI PARTNER=WSALES - UIDSOURCE=CURRENT RESTRICT=NONE |
|
|
Client Conversation |
Comments |
|
|---|---|---|
|
|
BEGIN OPEN PROCESS WKSALES . . Make inquiry . . CLOSE PROCESS WKSALES END |
Ad hoc request |
| Client Conversation | Comments | |
|---|---|---|
|
|
BEGIN OPEN PROCESS WKSALESU . . Make inquiry and update . . CLOSE PROCESS WKSALES END |
Application Subsystem request |
Coding for server
|
Server Network Definition |
Comments |
|
|---|---|---|
|
SYSOPT=X'nn' (X'10' bit on) |
Login required |
|
|
|
DEFINE LINK LINKSRV WITH - LOCALID=M204BO - DEFINE PROCESSGROUP SALES WITH - LINK=LINKSRV - REMOTEID=M204HQ - LOGIN=TRUST DEFINE PROCESS WSALES WITH - FROM=SALES - SUBSYSTEM=WKS - SUBSYSPARM='INQUIRY' DEFINE PROCESS WKSALESU WITH - FROM=SALES - SUBSYSTEM=WKS - SUBSYSPARM='UPDATE' |
|
|
Server Conversation |
Comments |
|
|---|---|---|
|
|
BEGIN OPEN PROCESS internalname ACCEPT . . IF request to update received IF %CMDLINE = 'UPDATE' CLOSE PROCESS internalname - ERROR END IF END IF . . CLOSE PROCESS internalname END |
|
Notes:
- There is a new process definition on the client side. The old name, WKSALES, was used for the inquiry-only process definition. The new definition, exclusive to the application subsystem, uses the name WKSALESU.
- On the server side, there are two process definitions, both invoking the same subsystem. However, the SUBSYSPARM parameter is added, which causes the quoted value to appear in the command-line variable when the subsystem is entered. This allows the subsystem to differentiate between a client user with only inquiry privileges and one with update privileges.
Note: The same end user can enter the service subsystem with different privileges:
- Writing one's own client request and entering with INQUIRY
- Using the application subsystem on the client side to enter with UPDATE
- Or, depending upon the SCLASS assigned, this end user may not have update privileges for any subsystem file.
Example 6: Accepting Guest Users
As more and more users on the client system want to use this application, the server system manager must define each client user in the server CCASTAT file or in an external security database. Since these users can only run in one application subsystem of the server system, the following revision places the responsibility for the subsystem's security in the hands of its administrator, and it takes the server's system manager out of the loop.
Coding for the client
|
Client Network Definition |
Comments |
|---|---|
|
DEFINE LINK LINKCLI WITH - LOCALID=M204HQ DEFINE PROCESSGROUP PGCLI WITH - LINK=LINKCLI - REMOTEID=M204BO - LOGIN=TRUST DEFINE PROCESS WKSALESU WITH - DESTINATION=PGCLI - PARTNER=WSALESU - UIDSOURCE=CURRENT - RESTRICT=APSY DEFINE PROCESS WKSALES WITH - DESTINATION=PGCLI - PARTNER=WSALES - UIDSOURCE=CURRENT - RESTRICT=NONE |
|
|
Client Conversation |
Comments |
|---|---|
|
BEGIN OPEN PROCESS WKSALES . . Do inquiry . . CLOSE PROCESS WKSALES END |
Ad hoc request |
| Client Conversation | Comments |
|---|---|
|
BEGIN OPEN PROCESS WKSALESU . . Do inquiry and update . . CLOSE PROCESS WKSALESU END |
Application Subsystem request |
Coding for the server
| Server Network Definition | Comments | |
|---|---|---|
|
SYSOPT=X'nn' (X'10' bit on) |
Login required |
|
|
|
DEFINE LINK LINKSRV WITH - LOCALID=M204BO - DEFINE PROCESSGROUP SALES WITH - LINK=LINKSRV - REMOTEID=M204HQ - LOGIN=TRUST - GUESTUSER=ACCEPT DEFINE PROCESS WSALES WITH - FROM=SALES - SUBSYSTEM=WKS - SUBSYSPARM='INQUIRY' DEFINE PROCESS WSALESU WITH - FROM=SALES - SUBSYSTEM=WKS - SUBSYSPARM='UPDATE' |
|
|
Server Conversation |
Comments |
|---|---|
|
OPEN PROCESS internalname ACCEPT . . IF request to update received IF %CMDLINE ¬= 'UPDATE' CLOSE PROCESS internalname - ERROR END IF END IF . . CLOSE PROCESS internalname END |
|
Notes:
- The only parameter change is the addition of the GUESTUSER=ACCEPT parameter on the processgroup definition on the server side. Client users from this particular processgroup no longer must be defined in CCASTAT.
- If the service subsystem is private, the subsystem administrator must define each prospective client user to the subsystem. If it is semipublic, only those client users that are in SCLASSes other than the default must be defined.