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. Figure 4‑1 shows Oracle Tuxedo Mainframe Adapter for SNA security elements.
Caution: Mixed environment security is more complex than depicted in Figure 4‑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 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 Figure 4‑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 MappingDirect 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 Oracle Tuxedo Mainframe Adapter for SNA 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 Figure 4‑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.With direct mapping, only security level IDENTIFY can be supported.Figure 4‑3 Direct User ID MappingSpecify parameters bearing on local domain and Oracle Tuxedo Mainframe Adapter for SNA security in the DMCONFIG and UBBCONFIG files in the following four sections:
• DM_LOCAL_DOMAINS section of the DMCONFIG file
• DM_SNALINKS section of the DMCONFIG file
• DM_ACCESS_CONTROL section of the DMCONFIG file
• RESOURCES section of the UBBCONFIG fileThe combined settings of the SECURITY parameters in the UBBCONFIG and the DMCONFIG files have the following effects:
• When the DM_LOCAL_DOMAINS security parameter is set to NONE or APP_PW, no action is taken by the Gateway with regard to security.
• However, when the UBBCONFIG file security parameter is set to APP_PW, the application password is validated by an AUTHSVC when clients join the application. The AUTHSVC is provided by the user application.
•
•
•
• The ATTACHSEC level for the connection definition in the host system must be set to IDENTIFY or VERIFY to match the DMCONFIG file DM_SNALINKS SECURITY parameter.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:
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.
•
•
•
•
• The ATTACHSEC level for the connection definition in the host system must be set to IDENTIFY or VERIFY to match the DMCONFIG file DM_SNALINKS SECURITY parameter.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:
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.Three sections in the DMCONFIG file contain parameters affecting Oracle Tuxedo Mainframe Adapter for SNA control of access to the ATMI local domain:
• DM_LOCAL_DOMAINS section contains a SECURITY parameter which specifies the type of security enforced for the ATMI local domain.
• DM_SNALINKS section contains a SECURITY parameter that records the security in effect for the host system.
• DM_ACCESS_CONTROL section contains local access control lists used by the ATMI local domain to associate local resources with host systems permitted to have access to them.
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.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 Oracle Tuxedo Mainframe Adapter for SNA 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”).This section of the DMCONFIG file is dedicated to Oracle Tuxedo Mainframe Adapter for 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 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:Specifies that a user identifier is not to be supplied by the remote system. LOCAL is the default value.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 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 Oracle Tuxedo 10.0 or 10gR3 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.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 Oracle Tuxedo Mainframe Adapter for SNA controls access to the ATMI local domain. This parameter takes the form:SECURITY = {value}In this parameter, value can be set as:Same as APP_PW, but additional authorization is required on a per-user basis.Same as 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.Same as 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 do not need to establish the SECURITY parameter settings, but examining this file enables you to see how Oracle Tuxedo Mainframe Adapter for SNA 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.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 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.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: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: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: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: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:
1. Edit the UBBCONFIG file.
a.
b.
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.
2. Enter the tmloadcf command to load the ATMI configuration, for example:
3. Set the application password. (The tmloadcf command prompts for the application password.)
4. Add users to the ATMI domain by using the tpusradd command. The command prompts for each password, for example:(Enter password for me.)
Note: Do not use the command tpaddusr.
5. Modify the ATMI client to specify security parameters in the tpinit call. Listing 4‑1 is an example of the code to do this.Listing 4‑1 Security Parameters Added to tpinit Call
7. Enter the dmloadcf command to load the domain configuration. For example:
8. Enter the tmboot command to boot the ATMI domain, for example:
9. Configure security for the SNA domain by editing the DMCONFIG file.
a. In the DM_LOCAL_DOMAINS section, add the parameter:
b. In the DM_SNALINKS section, add the parameter for the remote link:
10. Add the user name mapping for the remote domain by invoking dmadmin and using the addumap command to map local user IDs to remote user IDs. For example:
11. Add a password for remote user IDs for the remote domain by invoking dmadmin and using the addusr command to provide remote password(s). For example:CEDA EX GR(MYCONNGRP)Replace MYCONNGRP with the name of the group that contains your connection definitions.
2. Alter security of each connection definition by changing the value of ATTACHSEC to VERIFY on each connection definition.
3. Put each connection out of service by inquiring on the connection’s CEMT I CONN(MYCN) and tabbing to the connection, then changing the INS entry to OUT.CEDA I GR(MYCONNGRP)Replace MYCONNGRP with the name of the group that contains your connection definitions.To configure the previous example with a security level of IDENTIFY, complete the following steps:
1.
2.
3. Change the remote user password by using the addusr -w option so that no password is specified as in the following example:
Note: Figure 4‑4 Encrypted Links
1.
2.
1.
• If the CRM is started from the command line, add the -n option with the desired min and max, as described in SNACRM in Appendix A, “Administrative Command Reference Pages.”
• If the CRM is started as an ATMI server, modify the SNACRM server entry to contain the -n option with the desired min and max, as described in SNACRM in Appendix A, “Administrative Command Reference Pages.”If crmlkoff, crmlkon, or crmdown are used with encrypted CRM, no additional command line arguments are needed.Table 4‑3 lists the processes that support authentication.
Table 4‑3 CRM Processes Supporting Authentication Supports one-way authentication; CRM authenticates the crmlkon program, not vice versa Supports one-way authentication; CRM authenticates the crmlkoff program, not vice versa Supports one-way authentication; CRM authenticates the crmdown program, not vice versa Figure 4‑5 Authenticated Links
• Store the keyfile in a protected location.
2.
• Store the keyfile in a protected location.
• If the CRM is started from the command line, add the -u<keyfile> option, as described in SNACRM in Appendix A, “Administrative Command Reference Pages.”
• If the CRM is started as an ATMI server, modify the SNACRM server entry to contain the -u<keyfile> option as described in SNACRM in Appendix A, “Administrative Command Reference Pages.”
3. If crmlkoff, crmlkon, or crmdown are used with a CRM with authentication enabled, use the -u<keyfile> command line option as described in SNACRM in Appendix A, “Administrative Command Reference Pages.”