![]() |
![]() |
|
|
Setting Up Security for BEA eLink TCP for Tuxedo
The eLink for Mainframe TCP for Tuxedo (hereafter referenced as eLink TCP for Tuxedo) component supports security features that allows a requester from Tuxedo to pass a user ID 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 Tuxedo to Mainframe
The following figure illustrates the process flow for security verifications from eLink TCP for Tuxedo to a mainframe.
Figure 4-1 Security Checking for Tuxedo to Mainframe Transactions
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 user ID exactly.
Security Checking from Mainframe to Tuxedo
The following figure illustrates the process flow for security verifications from a mainframe to eLink TCP for Tuxedo.
Figure 4-2 Security Checking for Mainframe to Tuxedo Transactions
Note: To pass authority checking, the user's Tuxedo identity must match the mainframe user ID exactly.
Setting Up Security
The eLink TCP for Tuxedo product supports two methods for providing security:
Tuxedo Security Plug-in
The Tuxedo security plug-in enables the customization of the security functions, including the use of alternate implementations. The Tuxedo security plug-in is set up during Tuxedo plug-in configuration. Refer to the Tuxedo documentation for specific information about this feature.
Built-in Tuxedo Security
Built-in Tuxedo security is used when custom security plug-ins are not implemented.
To enable the built-in Tuxedo security feature, complete the following tasks.
Note: The user information in these files must match in the BEA Tuxedo and the mainframe environments or a security violation occurs.
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 user ID 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:
In these cases, a client's user ID, 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.
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*/
}
![]() |
![]() |
![]() |
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|