Determining Security Parameters for Inbound Requests

5.2.3.1.1 Determining Security Parameters for Inbound Requests

Configurations on Oracle Tuxedo Side

The following table shows settings for the SECURITY parameters in the UBBCONFIG and DMCONFIG files required to achieve local domain and host system security combinations for inbound requests from the host system.

Note:

Security setting combinations other than those shown in the tables will have unpredictable results.

Table 5-1 Security Settings for Inbound Requests from Host Systems

Security Combinations		Settings
Load	Host	`UBBCONFIG SECURITY`	`DM_LOCAL_DOMAI NS SECURITY`	`DM_SNALINKS SECURITY`	Remote Verification
No	No	`NONE or APP_PW`	`NONE or APP_PW`	`LOCAL`	Not Applicable
Yes	No	`USER_AUTH, ACL, or MANDATORY_ACL`	`DM_USER_PW`	`LOCAL`	INVALID
No	Yes	`NONE or APP_PW`	`NONE or APP_PW`	`IDENTIFY`	Not Applicable
Yes	Yes	`USER_AUTH, ACL, or MANDATORY_ACL`	`DM_USER_PW`	`IDENTIFY`	UID

For requests sent from the host system, the local domain extracts the remote user ID, or user ID and password, from the conversation start-up request and checks the domain security table. That table contains pairs of local principal user IDs and remote user IDs, maintained on a service-by-service basis. The remote user ID is mapped to the local principal user ID. The local principal user ID and password are used for further ACL checking, as specified in the UBBCONFIG file. If the direct user ID mapping option is specified, the remote user ID is used as the local principal user ID.

When a request is received from the host system, the local domain checks the ACL in the DMCONFIG file for the local service to see if requests from the remote domain are permitted. If the DMCONFIG file does not contain an ACL for the local service, the service is accessible to all requests.

Configurations on Mainframe Side

Before start, obtain the following information for each VTAM LU 6.2 pair from your VTAM system administrator:

The LU pair used in TMA and CICS communication: the local LU that can be used by CRM, and the partner LU used by CICS.
The network ID and the LU identifiers for each member of the pair.
Whether or not the NQNAME option is specified for the ACB. If it is specified, the network-qualified names support is enabled.

You can choose one of the following ways to configure CRM LU in z/OS:

Define the security profile

If the LU pair are enabled to support network-qualified names (NQN is specified on the LUADD statement), the RDEFINE syntax for both LU are:

RDEFINE APPCLU local-netid.luid1.remote-netid.luid2 UACC(NONE)
SESSION(SESSKEY(APPCPWD) CONVSEC(ALREADYV)

On another side:

RDEFINE APPCLU local-netid.luid2.remote-netid.luid1 UACC(NONE) + 
SESSION(SESSKEY(APPCPWD) CONVSEC(ALREADYV))

If both LU are not enabled to support network-qualified names (NONQN is specified on or used as the default for the LUADD statement), and both LU reside on network-id, the RDEFINE syntax for them are:
```
RDEFINE APPCLU local-netid.luid1.luid2 UACC(NONE) 
SESSION(SESSKEY(APPCPWD) CONVSEC(ALREADYV))
```
On another side:
```
RDEFINE APPCLU local-netid.luid2.luid1 UACC(NONE) +
SESSION(SESSKEY(APPCPWD) CONVSEC(ALREADYV))
```
local-netid/remote-netid: The network ID (NETID) of the partners. These IDs are specified in the VTAM start option NETID, which is in the ATCSTRxx member of SYS1.VTAMLST.

luid1/luid2: The LU names of the partners. In each case, the first LU name specified is the local LU name, and the second LU name is the partner LU name.

Note:

Do not specify an asterisk (*) or any other generic character for the first two qualifiers (netid and luid).
You need to confirm with Mainframe administrator whether NONQN or NQN must be specified.
Change VTAM APPL definition of CRM LU. The parameter SECACPT is required and its value should be ALREADYV.

Parent topic: Determining Security Parameters