Setting Up Security in Domains


	Corporate Info \| News \| Solutions \| Products \| Partners \| Services \| Events \| Download \| How To Buy
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| PDF Files \| Contact \| Glossary

Tuxedo Doc Home \| Administration \| Topic List \| Previous \| Next \| Contents

Using the BEA Tuxedo Domains Component

The BEA Tuxedo system provides the following standard security mechanisms:

Access Control Lists-restrict availability of services to authorized users whose names are included in lists that are automatically checked services are requested.
Authentication-verifies the identity of clients, servers, and administrative programs. The default security mechanism provided with the BEA Tuxedo system is an application authentication scheme that uses one password per BEA Tuxedo application. Clients are required to present this password before being allowed to join an application. Servers are authenticated to be running as the user identified as the administrator.
Encryption-security mechanisms to convert data to coded format that is unintelligible to users.
Security Plug-in Interface-allows installation of third-party security systems such as custom authentication and authorization. The plug-in interface is available to applications running BEA Tuxedo Release 7.1 or later software. For information on setting up security in domains using the security plug-in interface, see Establishing a Link Between Domains in Using BEA Tuxedo Security.

The BEA Tuxedo security mechanisms provided for individual applications and those provided for Domains configurations are relatively independent but compatible:

The BEA Tuxedo system provides the following security mechanisms for Domains configurations: authentication of remote domains; access control on exported local services for remote domains; and encryption mechanisms to protect interdomain communication.
If BEA Tuxedo system security is set to ACL or MANDATORY_ACL, then user IDs flow through the system with requests, and ACL checking takes place. If system security is set to USER_AUTH, then user IDs flow through the system, but no ACL checking takes place.
Even if you assign a security level of NONE to your BEA Tuxedo application, you can still set up Domains security to enforce security restrictions between domains. Note, however, that in order to use an application password in a Domains configuration, you must already have a value of APP_PW set for the security level in each participating application.

Domains Security Mechanisms

Because distinct domains may exist under different ownership, the native BEA Tuxedo application password scheme may not, of itself, provide sufficient security. Domains, therefore, provides additional security mechanisms:

Access Control Lists-Restrict availability of services in a local domain to a list of selected remote domains. You configure this security level in the DM_ACCESS_CONTROL section of DMCONFIG.
Domains Authentication-Techniques are required to ensure the proper identity of each remote domain. Domains provides three levels of password security: NONE specifies no authentication; APP_DW is authentication using the application password, which must match on the two domains; and DM_PW, which is authentication using specific passwords per local/remote domain pair. Each of these is selected by setting the SECURITY parameter in the DM_LOCAL_DOMAINS section for the local domain access point involved to the required level (APP_DW, DM_PW, NONE).
Link-Level Encryption-You can use encryption across domains to ensure data privacy. In this way, a network-based eavesdropper cannot learn the content of BEA Tuxedo messages or application-generated messages flowing from one domain gateway to another. You configure this security mechanism by setting the MINENCRYPTBITS and MAXENCRYPTBITS parameters in the DMCONFIG file.
Local Domains Access-Restricts local services to remote domains. If a service is not exported to remote domains, it is simply unavailable to them. A service is exported by placing an entry in the DM_LOCAL_SERVICES section of the DMCONFIG file for the service.
User Identity Mapping to Mainframes-Provides a mechanism whereby user identities within a domain can be mapped to and from external user identities. This mechanism is currently used by BEA eLink for Mainframe-SNA to map to and from RACF (remote access control facility) user names on IBM LU6.2 mainframes. To use this mechanism, refer to the following dmadmin configuration commands:
- addumap-Add local user mappings to remote user mappings for a local/remote domain pair. Mappings are defined to be inbound, outbound, or both.
- addusr-Add remote user names and passwords to the remote user and password tables of a remote domain.
- delumap-Delete local to remote user mappings for a local/remote domain pair.
- delusr-Delete remote user names and passwords from the remote user and password tables of a remote domain.
- modusr-Change remote passwords in the password tables of a remote domain.