|
|
|
|
| |
Providing Security
Security refers to techniques for ensuring that data stored in a computer or passed between computers is not compromised. Most security measures involve passwords and data encryption. A password is a secret word or phrase that gives a user access to a particular program or system, and data encryption is the translation of data into a form that is unintelligible without a deciphering mechanism.
This section covers the following topics:
Note: All references to ATMI files, functions, and documentation apply to Tuxedo files, functions, and documentation.
Understanding eLink Adapter for Mainframe Security
Distributed applications such as those used for electronic commerce (e-commerce) offer many access points for malicious people to intercept data, disrupt operations, or generate fraudulent input. The more distributed a business becomes, the more vulnerable it is to attack. Thus, the distributed computing software or middleware, upon which such applications are built must provide security.
BEA eLink Adapter for Mainframe works with the ATMI platform to enable the following security capabilities:
Mapping User IDs
User IDs are used to control access to system resources in the ATMI and mainframe environments. For user IDs to be used by those ATMI and mainframe environments, both sides must have security mechanisms in place. For the ATMI domain, the security mechanism is the Authorization Server. For the host system, the security mechanism is the External Security Manager. Figure4-1 shows eLink Adapter for Mainframe security elements.
The eLink Adapter for Mainframe software allows user IDs to be shared between domains in two ways:
Figure 4-1 eLink Adapter for Mainframe Security Elements
Caution: Mixed environment security is more complex than depicted in Figure4-1. A domain without an operational security mechanism in place accepts all transaction requests by treating user IDs as "trusted users." Refer to the appropriate ATMI product documentation for more detailed information about domain security.
ATMI-to-Host User ID Mapping
ATMI-to-host user ID mapping associates a user ID in the local domain with a corresponding user ID in the host system. With ATMI-to-host user ID mapping, an ATMI user ID can be different from its counterpart on the host. See Figure4-2.
The dmadmin commands are used to create this kind of mapping. Refer to the "Using dmadmin Commands to Administer User ID Mapping" section. These commands change the binary form of the DMCONFIG file (called the BDMCONFIG file).
Figure 4-2 Typical ATMI-to-host User ID Mapping
Direct User ID Mapping Direct user ID mapping enables the direct mapping of an
ATMI user ID to an identical host user ID. This eliminates the need to use the
dmadmin commands, as with
ATMI-to-host user ID mapping. When this feature is used, any user ID mappings in
the BDMCONFIG file are bypassed.
To enable this feature, specify a command-line parameter with the GWSNAX command when starting the eLink
Adapter for Mainframe Gateway. Refer to the "Bypassing User ID
Mapping" section. Note: When direct
user ID mapping is used, modification or elimination of any BDMCONFIG file mapping entries is not
necessary. With direct user ID mapping, the user IDs in the ATMI
and host environments must be identical as shown in Figure4-3. When the
ATMI local domain initiates a request, the ATMI user ID is applied to the
requested host service. When the host initiates a request, the host user ID is
applied to the requested ATMI service. Notes: Identical
user IDs must exist in the local domain and in the host domain for direct user
ID mapping to be used. With direct mapping, only security level IDENTIFY can be supported. Figure 4-3 Direct User ID Mapping
Configuring User ID Mapping Specify parameters bearing on local domain and eLink
Adapter for Mainframe security in the DMCONFIG and UBBCONFIG files in the following four
sections:
Determining Security Parameters
The combined settings of the SECURITY parameters in the UBBCONFIG and the DMCONFIG files have the following effects:
If security is to be enforced by both the local domain and the host system for each request inbound from the host system to the local domain, the following settings must be made:
Determining Security Parameters for Inbound Requests
Table 4-1 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.
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.
Determining Security Parameters for Outbound Requests
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:
Table 4-2 shows settings for the SECURITY parameters in the UBBCONFIG and DMCONFIG files required to achieve local domain and host system security combinations for outbound requests.
Note: Security setting combinations other than those shown in the tables will have unpredictable results.
For a request sent to the host system, the local principal user ID is located in the domain security table and the associated remote user ID, or user ID and password, are put into the conversation start-up request before being sent over the LU6.2 conversation. This situation occurs if SECURITY is set to IDENTIFY or VERIFY in the DM_SNALINKS section of the DMCONFIG file. If the direct user ID mapping option is specified, the local principal user ID is put into the conversation startup request.
Setting DMCONFIG File Security Parameters
Three sections in the DMCONFIG file contain parameters affecting eLink Adapter for Mainframe control of access to the ATMI local domain:
Caution: Do not delete the DMCONFIG binary file before running the dmloadcf command. Tables of remote users, remote passwords, and remote mappings are stored in this file. If deleted, all security information must be re-entered.
DM_LOCAL_DOMAINS Section
The SECURITY parameter settings in this section work in conjunction with the SECURITY parameter in the RESOURCES section of the ATMI local domain's UBBCONFIG file to establish how eLink Adapter for Mainframe controls access to the ATMI local domain. The parameter takes the form:
SECURITY = {value}In this parameter, value can be set as:
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 "Setting DMCONFIG File Security Parameters").
DM_SNALINKS Section
This section of the DMCONFIG file is dedicated to eLink Adapter for Mainframe 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 ATMI domain and local refers to the host system. The parameter takes the form:
SECURITY_TYPE = {value}In this parameter, value can be set as:
The values LOCAL and IDENTIFY are roughly equivalent to NONE and APP_PW for the SECURITY parameter in the DMCONFIG file.
DM_ACCESS_CONTROL Section
This section contains local ACL used by the ATMI local domain to restrict access by remote regions to local resources. Refer to the "ATMI Security Administration" section in the BEA Tuxedo 8.0 documentation.) 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.
Setting UBBCONFIG File Security Parameters
The RESOURCES section in this file contains a SECURITY parameter that works in conjunction with the SECURITY parameter in the DMCONFIG file to establish how eLink Adapter for Mainframe controls access to the ATMI local domain. This parameter takes the form:
SECURITY = {value}In this parameter, value can be set as:
In most cases, the UBBCONFIG file has already been configured and you do not need to establish the SECURITY parameter settings, but examining this file enables you to see how eLink Adapter for Mainframe enforces security.
If this parameter is set to NONE, no security is enforced. If set to APP_PW, the local ATMI 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.
Bypassing User ID Mapping
To use direct user ID mapping, use the -m parameter in the GWSNAX process start-up command line entry. This parameter allows you to establish direct user ID mapping, rather than ATMI-to-host user ID mapping.
Note: If you bypass user ID mapping, the local and host domains must have identical user IDs in effect, otherwise a security error occurs.
For example, to set the Gateway server process to bypass user ID mapping, enter a command in the following format:
GWSNAX SRVGRP = <groupname> SRVID = <number> CLOPT = "-A -- -m"
Refer to GWSNAX in Appendix A, "Administrative Command Reference Pages" for more information.
Using dmadmin Commands to Administer User ID Mapping
When ATMI-to-host user ID mapping is used, you must create mappings in the BDMCONFIG file.
Note: If the direct user ID mapping option is specified, creation of mappings in the BDMCONFIG file is not necessary. Any mappings in the BDMCONFIG file are ignored.
User ID mapping between the local domain and the host system is configured using the addumap, addusr, delumap, modusr, and delusr commands of the dmadmin utility to accomplish the following tasks:
Refer to Appendix A, "Administrative Command Reference Pages" for more information about each ATMI command.
To use these commands, enter dmadmin at the system prompt. At the dmadmin ">" prompt, enter the commands as described.
Adding a User ID and Password
Use the addusr ATMI command to add an ATMI local domain user ID and password to the remote domain user and password file. Enter the following command:
addusr {-d} local_domain_id {-R} remote_domain_id {-u} remote_userid [{-w}]The arguments and options in this command are defined in the following way:
Mapping a User ID
Use the addumap ATMI command to map a local domain principal user ID number to a remote domain user name. The user ID must be added before it can be mapped. Refer to the "Adding a User ID and Password" section. Enter the following command:
addumap {-d} local_domain_id {-R} remote_domain_id
{-p} local_principal_userid {-u} remote_useridThe arguments and options in this command are defined in the following way:
Removing User ID Mapping
Use the delumap ATMI command to remove the mapping for a local domain principal user ID 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_useridThe arguments and options in this command are defined in the following way:
Deleting a User ID and Password
Use the delusr ATMI command to remove a local ATMI domain user ID and password from the remote domain user and password file. The mapping for a user ID must be removed before the user ID can be removed. Enter the following command:
delusr {-d} local_domain_id {-R} remote_domain_id {-u} remote_useridThe arguments and options in this command are defined in the following way:
Modifying a Password
Use the modusr ATMI command to modify a local domain user's password recorded in a remote domain's user and password file. Enter the following command:
modusr {-d} local_domain_id {-R} remote_domain_id {-u} remote_userid [{-w}]The arguments and options in this command are defined in the following way:
Setting Security Scenario
This section provides an example of step-by-step instructions for setting up security in an application that has already been configured.
Configuring Security in the ATMI Domain
Note: SECURITY USER_AUTH level implies that application passwords, user IDs, and user passwords are required to join the application. AUTHSVR is the ATMI-supplied authentication server. It advertises the service AUTHSVC.
tmloadcf -y ubbconfig.sna
tpusradd me
(Enter password for me.)
Note: Do not use the command tpaddusr.
Listing 4-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);
}
dmloadcf -y dmconfig.sna
tmboot -y
SECURITY=DM_USER_PW
SECURITY=VERIFY
dmadmin
>addumap -d myldom -R myrdom -p localme -u REMOTEME
dmadmin
>addusr -d myldom -R myrdom -u REMOTEME
(The system responds with the following prompts:
ERROR: Enter Remote User's Password:
ERROR: Re-enter Remote User's
Password:)
Configuring Security in the Local Domain
To configure security in the local domain:
Refer to the appropriate stack documentation.
Configuring Security in the Remote Domain
Change the security of connection definitions on the mainframe host by doing the following:
CEDA EX GR(MYCONNGRP)
Replace MYCONNGRP with the name of the group that contains your connection definitions.
CEDA I GR(MYCONNGRP)
Replace MYCONNGRP with the name of the group that contains your connection definitions.
Setting the Security Level to IDENTIFY
To configure the previous example with a security level of IDENTIFY, complete the following steps:
Using Encryption
To establish secure communications between the Communication Resource Manager (CRM) and the Gateway (GWSNAX) over a distributed network, eLink Adapter for Mainframe uses a link-level encryption process.
Illustration of Encryption Process
As illustrated in the following diagram, this encryption feature only applies to the link between the eLink Adapter for Mainframe Gateway and the CRM.
Note: The appropriate ATMI security add-on (40 bit or 128 bit) must be purchased to enable encryption.
Figure 4-4 Encrypted Links
The encryptions process occurs in the following
way:
Each process has a range of acceptable encryption levels, as specified on the process start-up command line. The lowest common level of encryption is used.
Note: When encryption is established for communications between the CRM and the Gateway, system performance may deteriorate. The higher the encryption level, the more likely deterioration may occur.
Configuring the eLink Adapter for Mainframe Gateway and CRM for Encryption
To configure the eLink Adapter for Mainframe Gateway:
See GWSNAX in Appendix A, "Administrative Command Reference Pages."
To configure the CRM:
If crmlkoff, crmlkon, or crmdown are used with encrypted CRM, no additional command line arguments are needed.
Using TCP/IP Link Authentication
In addition to encryption, eLink Adapter for Mainframe uses an authentication process to establish secure communications between the CRM and Gateway over a distributed network.
Table 4-3 lists the processes that support authentication.
Table 4-3 CRM Processes Supporting Authentication
Illustration of Authentication
Process As illustrated in the following diagram, this
authentication feature only applies to the link between the Gateway and the
CRM. Figure 4-5 Authenticated Links
When the Gateway establishes a connection to the CRM,
the following events occur:
Configuring the eLink Adapter for Mainframe Gateway and CRM for Authentication
To configure the Gateway for authentication, complete the following steps:
[-u <keyfile>]
To configure the CRM:
Using Third-Party Security Software
The Tuxedo security plug-in allows users to customize security functions and use alternate implementations of third-party security software. The Tuxedo security plug-in is set up during Tuxedo plug-in configuration. Refer to the Tuxedo documentation for specific information about this feature.
 |
 |
 |
|
|
|
Copyright
© 2001 BEA Systems, Inc. All rights reserved. |