|  | BEA eLink TCP for TUXEDO 3.1 Information Center
HOME | SEARCH | CONTACT | PDF FILES | WHAT'S NEW
| TABLE OF CONTENTS | PREVIOUS TOPIC | NEXT TOPIC | INDEX

# Setting Up Security for BEA eLink TCP for TUXEDO

The eLink for Mainframe TCP for TUXEDO (hereafter referenced as eLink TCP for TUXEDO) product supports a security feature that allows a requester from TUXEDO to pass a USERID requirement through the OTMA or CICS server interfaces for verification through system security, such as RACF. This document explains the following security topics:

- Security Checking from UNIX to Mainframe

- Security Checking from Mainframe to UNIX

- Setting Up Security

- Sample Security Files

- Data Area Security

  ## Security Checking from UNIX to Mainframe

  Figure 4-1 depicts the process flow for security verifications from eLink TCP for TUXEDO on UNIX to a mainframe.

  > Figure 4-1 Security Checking for UNIX to Mainframe Transactions

  1. When the client program performs a `tpinit()`, the user's TUXEDO identity is validated against the `tpusr` file.

  2. When the client program issues a `tpcall()` or `tpacall()`, TUXEDO verifies (against the `tpacl` file) that the user is authorized to invoke the gateway service.

  3. When the gateway establishes the initial connection, connection security information (specified as RMTNAME and PASSWORD in the GWICONFIG file) is passed from the eLink TCP for TUXEDO gateway to the remote gateway. If the RMTNAME and PASSWORD values match the values configured on the remote gateway, the connection is established.

     With each request, the eLink TCP for TUXEDO gateway passes the user's TUXEDO identity to the remote gateway.

     Note: To pass authority checking, the user's TUXEDO identity must match the mainframe userid exactly.

  4. The remote mainframe gateway initiates a proxy to act on behalf of the specified userid.

  5. The proxy calls the specified service using system security to check authorization.

  ## Security Checking from Mainframe to UNIX

  Figure 4-2 depicts the process flow for security verifications from a mainframe to eLink TCP for TUXEDO on UNIX.

  > Figure 4-2 Security Checking for Mainframe to UNIX Transactions

  1. The userid, established at mainframe log in, is checked by system security to verify that the user has permission to start a client transaction.

  2. The userid is checked by system security to verify that the user has permission to send a request to the gateway.

  3. With each request, the gateway passes the userid to the TUXEDO gateway.

     Note: To pass authority checking, the user's TUXEDO identity must match the mainframe userid exactly.

  4. The eLink TCP for TUXEDO gateway maps the mainframe userid to a TUXEDO userid and issues the service request on behalf of that user.

  5. The TUXEDO server performs access checks (based on the `tpacl` file) to verify that the user has access to the requested service.

  ## Setting Up Security

  Complete the following tasks to enable the security feature.

  - Code SECURITY in the BEA TUXEDO UBBCONFIG file. Refer to the BEA TUXEDO Administration Guide for more information.

  - Set up user, group, and ACL files. Refer to the BEA TUXEDO Administrator's Guide for more information.

    Note: The user information in these files must match in the BEA TUXEDO and the mainframe environments or a security violation occurs.

  - Code the security parameter in your eLink TCP for TUXEDO configuration file (GWICONFIG). For GWICONFIG syntax and parameter definitions, refer to "Configuring BEA eLink TCP for TUXEDO."

  ## Sample Security Files

  Part of the process for setting up security for eLink TCP requires you to have user, group, and ACL files. The following sections include these sample files.

  ### User Files

  The following sample is a user file that includes user names, encrypted passwords, a userid number, group number, and a client name.

  > Listing 4-1 Sample User (tpusr) File

  >     #illen:w2ZMOKeJmiU0M:1:0:TPCLTNM,someguy::
  >     #illen:0YzvQeqzcNz56:1:0:TPCLTNM,*::
  >     #eke:x3vG37eOqh0XE:2:0:TPCLTNM,*::
  >     #illen:0YzvQeqzcNz56:1:1:TPCLTNM,*::
  >     #illen:0YzvQeqzcNz56:1:2:TPCLTNM,*::
  >     john:x3vG37eOqh0XE:2:1:TPCLTNM,*::
  >     jim:0YzvQeqzcNz56:1:1:TPCLTNM,*::
  >     richard:IxqosKHu5Q3BA:3:1:TPCLTNM,*::
  >     JDOE:zBMWVUBNNBVgo:4:0:TPCLTNM,*::
  >     smith:ULfRJzAeyGAD2:5:0:TPCLTNM,*::

  Lines that begin with the pound sign (#) are users that have been changed or deleted by `tpusrmod` or `tpusrdel`.

  ### Group File

  The following sample is a group file that specifies the names and indexes of groups.

  Note: The `tpgrp` file is only necessary when specifying ACL or MANDATORY_ACL modes for security. If you specify USER_AUTH for security, you can assign users to groups, but they do not correlate to the groups used for security by the remote system.

  > Listing 4-2 Sample Group (tpgrp) File

  >     good::1:
  >     bad::2:

  ### ACL File

  The `tpacl` file correlates a group and the services to which that group has access. In the `tpacl` file, the first field specifies what is protected, the second field specifies the type of object being protected (specified in the first field), and the third field specifies the group that has access to the object.

  In the following example, only users in group 1 (john, jim, richard) can access TOLOWER, and only users in group 2 can access TOUPPER.

  Note: The `tpacl` file is only necessary when specifying ACL or MANDATORY_ACL modes for security.

  > Listing 4-3 Sample ACL (tpacl) File

  >     TOLOWER:SERVICE:1:
  >     TOUPPER:SERVICE:2:

  ## Data Area Security

  The eLink TCP for TUXEDO gateway provides data area security which is a specialized security protocol for the following cases:

  - User information is propagated across multiple TUXEDO domain boundaries

  - A remote or local service requires a user's LTERM information

  In these cases, a client's USERID, group name, and LTERM can be specified in the data area of a request. For TUXEDO clients, user information specified in the data area is verified by the remote gateway in the usual manner. For remote clients, remote user information is placed in the data area fields by the local gateway to be used by TUXEDO services. In this case, the remote client does not have to populate these fields, but must allocate space for them in the data area.

  ### Enabling Data Area Security

  Complete the following tasks to enable data area security.

  1. Add fields to the user's data area on the local and remote hosts. These fields are passed to and from the mainframe host. For the field formats, refer to Listing 4-4.

  2. Set WRAP=TPSD in the FOREIGN section corresponding to the remote host in the GWICONFIG file. For syntax and parameter definitions for the FOREIGN section of the GWICONFIG file, refer to "Defining the FOREIGN Section of the GWICONFIG File."

  3. Populate the data area with the user information before sending a request to a remote service.

  4. The remote user's information is populated into the data area when a request is received for a local service.

     Note: If using a VIEW data format, allocate the extra fields before the application data as defined in Listing 4-4. If using the STRING data format, allocate 24 additional bytes at the beginning of the string to be used for the security fields.

  ### Format

  The user data area fields in C use the following format.

  > Listing 4-4 Syntax for C User Data Area Fields

  >     struct da_security {
  >            char uname[8];  /*user name*/
  >            char group[8];  /*user group*/
  >            char lterm[8];  /*terminal id*/
  >            /*user data is appended here*/
  >     }

  TABLE OF CONTENTS | PREVIOUS TOPIC | NEXT TOPIC | INDEX