HOME | SEARCH | CONTACT | PDF FILES | WHAT'S NEW
TABLE OF CONTENTS | PREVIOUS TOPIC | NEXT TOPIC
|
|
|
BEA eLink for Mainframe SNA 3.2 Information Center |
|
HOME | SEARCH | CONTACT | PDF FILES | WHAT'S NEW |
||
|
TABLE OF CONTENTS | PREVIOUS TOPIC | NEXT TOPIC |
||
This subsection covers the following topics:
In order for any security checking to occur, the BEA TUXEDO Local Domain and the Host System must have security mechanisms in place. For the Local Domain, this is the Authorization Server. For the Host System, this is the External Security Manager. Figure 6-1 shows these elements.
There are four sections in two BEA TUXEDO configuration files in which you specify parameters bearing on Local Domain security. The two configuration files are DMCONFIG and UBBCONFIG.
Userid and password mapping between the Local Domain and the Host System also bears on security. There are five
Caution:
Mixed environment security is more complex than depicted in Figure 6-1. A domain without an operational security mechanism in place accepts all transaction requests by treating userids as "trusted users." Refer to BEA TUXEDO documentation for more detailed information about domain security.
The configuration sections where security is specified are:
Security Overview
DMADMIN subcommands which you use to enter userids and passwords, set up mappings, remove mappings, remove userids and passwords, and modify passwords.
Figure 6-1 BEA eLink for Mainframe SNA Security Elements
Where You Specify Security Parameters
RESOURCES section of the UBBCONFIG file
DM_LOCAL_DOMAINS section of the DMCONFIG file
The where UBBCONFIG File Security Parameters
RESOURCES section in this file contains a SECURITY parameter which works in conjunction with the SECURITY parameter in the DMCONFIG file to establish how eLink SNA controls access to the BEA TUXEDO local domain. This parameter takes the form:
SECURITY = {value}value is:
NONE
APP_PW
USER_AUTH
APP_PW, but additional authorization is required on a per-user basis.
ACL
USER_AUTH, but additional access-control checks are done on service names, queue names, and event names. If no Access Control Lists (ACL) exists for a given name, access is granted.
MANDATORY_ACL
ACL, but if no ACL exists for a given name, access is denied.
In most cases, the UBBCONFIG file has already been configured and you don't need to establish the SECURITY parameter settings, but examining this file enables you to ascertain how eLink SNA enforces security.
If this parameter is set to NONE, no security is enforced. If set to APP_PW, the local BEA TUXEDO domain's Authorization Server prompts for the application password. If set to USER_AUTH, ACL, or MANDATORY_ACL, the qualified security is enforced as specified.
Three sections in the DMCONFIG file contain parameters affecting eLink SNA control of access to the BEA TUXEDO local domain:
DM_LOCAL_DOMAINS section contains a SECURITY parameter which specifies the type of security enforced for the BEA TUXEDO local domain.
The where DM_LOCAL_DOMAINS section
SECURITY parameter settings in this section work in conjunction with the SECURITY parameter in the RESOURCES section of the BEA TUXEDO local domain's UBBCONFIG file to establish how eLink SNA controls access to the BEA TUXEDO local domain. The parameter takes the form:
SECURITY = {value}value is:
NONE
APP_PW
DM_USER_PW
If this parameter is set to NONE or APP_PW, the local domain takes no action with regard to security. If this parameter is set to DM_USR_PW, the local domain enforces security according to the setting in the UBBCONFIG file (refer to "UBBCONFIG File Security Parameters").
This section of the DMCONFIG file is dedicated to eLink SNA parameters. It records the security in effect for the host system. It correlates to the values set for the ATTACHSEC parameter in the connection resource definition. In the following parameter definition, remote refers to the TUXEDO domain and local refers to the host system. The parameter takes the form:
SECURITY_TYPE = {value}where value is:
LOCAL
LOCAL is the default value.
IDENTIFY
VERIFY
PERSISTENT
MIXIDPE
The values LOCAL and IDENTIFY are roughly equivalent to NONE and APP_PW for the SECURITY parameter in the DMCONFIG file.
This section contains local Access Control Lists (ACL) used by the BEA TUXEDO local domain to restrict access by remote regions to local resources. (Refer to "Security Administration" in the BEA TUXEDO Administrator's Guide.) Each entry consists of an ACL_NAME resource identifier along with a list of required parameters designating remote domains permitted to access the resource. If no entry exists for a local service, the service is accessible to all remote domains.
The domain administrator can add or delete users from the domain security table in two ways: first, through data entry panels in the TUXEDO System administration Graphical Administrative Interface; second, by using the dmadmin command.
The combined settings of the SECURITY parameters in the UBBCONFIG and the DMCONFIG files have the following effects:
DM_LOCAL_DOMAINS Security parameter is set to NONE or APP_PW, no action is taken by the eLink SNA gateway with regard to security.
UBBCONFIG file SECURITY parameter must be set to one of USER_AUTH, ACL, or MANDATORY_ACL;
DMCONFIG file DM_LOCAL_DOMAINS section SECURITY parameter must be set to DM_USER_PW
DM_SNALINKS SECURITY parameter must be set to IDENTIFY or VERIFY.
(Refer to Table 6-1 for a summary of the file settings required to achieve different security combinations for inbound requests from the host system.)
If security is to be enforced by both the local domain and the host system for each request outbound from the local domain, the following settings must be made:
UBBCONFIG file SECURITY parameter must be set to one of USER_AUTH, ACL, or MANDATORY_ACL
DM_LOCAL_DOMAINS section SECURITY parameter must be set to DM_USER_PW
DM_SNALINKS SECURITY parameter must be set to IDENTIFY or VERIFY
(Refer to Table 6-2 for a summary of the file settings required to achieve different security combinations for outbound requests from the local domain.)
For a request sent to the host system, the local principal userid is located in the domain security table and the associated remote userid, or userid and password, are put into the conversation start-up request before being sent over the LU6.2 conversation. (This occurs if For requests sent from the host system, the local domain extracts the remote userid, or userid and password, from the conversation start-up request and checks the domain security table. That table contains pairs of local principal userids and remote userids, maintained on a service-by-service basis. The remote userid is mapped to the local principal userid. The local principal userid and password are used for further Access Control List (ACL) When a request is received from the host system, the local domain checks the Therefore, if the Table 6-1 shows settings for the
Note:
Security setting combinations other than those shown in the tables will have unpredictable results.
SECURITY is set to IDENTIFY or VERIFY in the DM_SNALINKS section of the DMCONFIG file.)
checking, as specified in the UBBCONFIG file.
DMCONFIG file ACL 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.
ATTACHSEC level for the connection definition in the host system is Identify or Verify, the DMCONFIG SECURITY parameter must be set to DM_USER_PW so that a userid and a password are sent on the conversation start-up requests.
Security Setting Summary Tables
SECURITY parameters in the UBBCONFIG and DMCONFIG files required to achieve local domain and host system security combinations for inbound requests.
Table 6-2 shows settings for the
Note:
Security setting combinations other than those shown in the tables will have unpredictable results.
SECURITY parameters in the UBBCONFIG and DMCONFIG files required to achieve local domain and host system security combinations for outbound requests.
This subsection gives step-by-step instructions for setting up security in an application that has already been configured.
Setting Up Security in a Configured Application
Configuring Security in the TUXEDO Domain
tmloadcf command to load the TUXEDO configuration, for example:
tmloadcf -y ubbconfig.sna
tmloadcf command prompts for the
application password.)
(Enter password for
Note:
Do not use the command tpusradd me
me.)
tpaddusr.
tpinit call.
Listing 6-1 is an example of the code to do this.
Listing 6-1
Security Parameters Added to
tpinit Call
TPINIT *tpinitbuf;
char passwd[30];
int security_level;/* Initialize security parameters */
if ((tpinitbuf = (TPINIT *) tpalloc("TPINIT", NULL,
TPINITNEED(sizeof(passwd)))) == NULL) {
userlog("tpalloc tpinit failed %s \n", tpstrerror(tperrno));
exit(1);
}
strcpy(tpinitbuf->usrname,"");
strcpy(tpinitbuf->cltname,"");
strcpy(tpinitbuf->passwd,"");
strcpy(tpinitbuf->grpname,"");/* Determine level of enforced security */
security_level = tpchkauth();
if ((security_level == TPSYSAUTH) || (security_level ==
TPAPPAUTH)) {
fprintf(stdout,"\nApplication passwd required.");
fprintf(stdout,"\nApplication passwd:");
gets(tpinitbuf->passwd);
} if (security_level == TPAPPAUTH)
{
fprintf(stdout,"\nUser Name required.");
fprintf(stdout,"\nUser Name:");
gets(tpinitbuf->usrname);
fprintf(stdout,"\nUser Password required.");
fprintf(stdout,"\nUser Password:");
gets(passwd);
strcpy(&tpinitbuf->data,passwd);
tpinitbuf->datalen=strlen(passwd);
} if (tpinit(tpinitbuf) == -1)
{
userlog("TPINIT %s \n", tpstrerror(tperrno));
exit(1);
}
dmload command to load the domain configuration, for example:
dmloadcf -y dmconfig.sna
tmboot command to boot the TUXEDO domain, for example:
tmboot -y
SECURITY=DM_USER_PW
dmadmin and using
the addumap command to map local user IDs to remote user IDs, for example:
dmadmin
addumap -d mylocaldomain -R myremotedomain -p localme -u REMOTEMEdmadmin
and using the addusr command to provide remote password(s), for example:
(The system responds with the following prompts:
dmadmin
addusr -d mylocaldomain -R myremotedomain -u REMOTEMEERROR: Enter Remote User's Password:)
ERROR: Re-enter Remote User's Password:
CEDA EX GR(MYCONNGRP)
Set ATtachsec = VERIFY
and tabbing to the connection, then changing the INS entry to OUT.
CEDA I GR(MYCONNGRP)
If you want to set the security level to IDENTIFY, then change the SECURITY parameter in the DMCONFIG to IDENTIFY and change the ATtachsec parameter on the connection to IDENTIFY. Change the remote user password by using the addusr -w option so that no password is specified, for example:
addusr -d mylocaldomain -R myremotedomain -u REMOTEME -w)
Once the user security information in both domains is mapped, you can perform administration on the affected security files in each domain. To do this, use the addumap, dmadmin, delumap, modusr, and delusr subcommands.
The following paragraphs discuss how you enter these commands. Refer to Appendix A, "Reference Pages," for detailed information about each subcommand.
Use the addusr subcommand to add a BEA TUXEDO local domain's userid and password to the remote CICS/ESA domain's user and password file. Enter the following command:
addusr {-d} local_domain_id {-R} remote_domain_id {-u} remote_useridwhere:
-d
-R
-u
Use the addumap subcommand to map a local domain principal userid number to a remote domain user name. The userid must be added before it can be mapped (refer to "Adding a Userid and Password"). Enter the following command:
addumap {-d} local_domain_id {-R} remote_domain_id
{-p} local_principal_userid {-u} remote_useridwhere:
-d
-R
-p
-u
Use the delumap subcommand to remove the mapping for a local domain principal userid to a remote domain user name. Enter the following command:
delumap {-d} local_domain_id {-R} remote_domain_id
{-p} local_principal_userid {-u} remote_useridwhere:
-d
-R
-p
-u
Use the delusr subcommand to remove a local BEA TUXEDO domain's user ID and password from the CICS/ESA remote domain's user and password file. The mapping for a userid must be removed before the userid can be removed (refer to "Removing a Userid's Mapping"). Enter the following command:
delusr {-d} local_domain_id {-R} remote_domain_id {-u} remote_useridwhere:
-d
-R
-u
Use the modusr subcommand to modify a local BEA TUXEDO domain user's password recorded in a CICS/ESA remote domain's user and password file. Enter the following command:
modusr {-d} local_domain_id {-R} remote_domain_id {-u} remote_useridwhere:
-d
-R
-u
