This topic includes the following sections:
Notes: | The BEA Tuxedo CORBA Java client and BEA Tuxedo CORBA Java client ORB were deprecated in Tuxedo 8.1 and are no longer supported. All BEA Tuxedo CORBA Java client and BEA Tuxedo CORBA Java client ORB text references, associated code samples, should only be used to help implement/run third party Java ORB libraries, and for programmer reference only. |
Note: | Technical support for third party CORBA Java ORBs should be provided by their respective vendors. BEA Tuxedo does not provide any technical support or documentation for third party CORBA Java ORBs. |
Link-Level Encryption (LLE) establishes data privacy for messages moving over the network links. The objective of LLE is to ensure confidentiality so that a network-based eavesdropper cannot learn the content of BEA Tuxedo system messages or CORBA application-generated messages. It employs the symmetric key encryption technique (specifically, RC4), which uses the same key for encryption and decryption.
When LLE is being used, the BEA Tuxedo system encrypts data before sending it over a network link and decrypts it as it comes off the link. The system repeats this encryption/decryption process at every link through which the data passes. For this reason, LLE is referred to as a point-to-point facility.
LLE can be used to encrypt communication between machines and/or domains in a CORBA application..
Note: | LLE cannot be used to protect connections between remote CORBA client applications and the IIOP Listener/Handler. |
There are three levels of LLE security: 0-bit (no encryption), 56-bit (Export), and 128-bit (Domestic). The Export LLE version allows 0-bit and 56-bit encryption. The Domestic LLE version allows 0, 56, and 128-bit encryption.
LLE works in the following way:
For convenience, the two parameters are denoted as (min
, max
). For example, the values (56, 128) for a process mean that the process accepts at least 56-bit encryption but can support up to 128-bit encryption.
Figure 3-1 illustrates these steps.
When two processes at the opposite ends of a network link need to communicate, they must first agree on the size of the key to be used for encryption. This agreement is resolved through a two-step process of negotiation.
When either of the two processes starts up, the BEA Tuxedo system (1) checks the bit-encryption capability of the installed LLE version by checking the LLE licensing information in the lic.txt
file and (2) checks the LLE min-max
values for the particular link type as specified in the two configuration files. The BEA Tuxedo system then proceeds as follows:
min
-max
values accommodate the installed LLE version, then the local software assigns those values as the min
-max
values for the process.min
-max
values do not accommodate the installed LLE version, for example, if the Export LLE version is installed but the configured min
-max
values are (0, 128), then the local software issues a run-time error; link-level encryption is not possible at this point.min
-max
values specified in the configurations for a particular link type, then the local software assigns 0 as the minimum value and assigns the highest bit-encryption rate possible for the installed LLE versions as the maximum value, that is, (0, 128) for the Domestic LLE version.
After the min
-max
values are determined for the two processes, the negotiation of key size begins. The negotiation process need not be encrypted or hidden. Once a key size is agreed upon, it remains in effect for the lifetime of the network connection.
Table 3-1 shows which key size, if any, is agreed upon by two processes when all possible combinations of min
-max
values are negotiated. The header row holds the min
-max
values for one process; the far left column holds the min
-max
values for the other.
The length of time a Workstation client can take for initialization is limited. By default, this interval is 30 seconds in an application not using LLE, and 60 seconds in an application using LLE. The 60-second interval includes the time needed to negotiate an encrypted link. This time limit can be changed when LLE is configured by changing the value of the MAXINITTIME
parameter for the Workstation Listener (WSL) server in the UBBCONFIG
file, or the value of the TA_MAXINITTIME
attribute in the T_WSL
class of the WS_MIB
(5).
To use LLE in a CORBA application, you need to install a license that enables the use of LLE. For information about installing the license, see Installing the BEA Tuxedo System.
The implementation of LLE is an administrative task. The system administrators for each CORBA application set min
-max
values in the UBBCONFIG
file that control encryption strength. When the two CORBA applications establish communication, they negotiate what level of encryption to use to exchange messages. Once an encryption level is negotiated, it remains in effect for the lifetime of the network connection.
The CORBA security environment supports a password mechanism to provide authentication to existing CORBA applications and to new CORBA applications that are not prepared to deploy a full Public Key Infrastructure (PKI). When using password authentication, the applications that initiate invocations on CORBA objects authenticate themselves to the BEA Tuxedo domain using a defined username and password.
The following levels of password authentication are provided:
When using Password authentication, you have the option of using the Tobj::PrincipalAuthenticator::logon()
or the SecurityLevel2::PrincipalAuthenticator::authenticate()
methods in your client application.
If you use password authentication, the SSL protocol can be used to provide confidentiality and integrity to communication between applications. For more information, see The SSL Protocol.
Password authentication works in the following way:
PrincipalAuthenticator
object. The request for authentication is sent to the IIOP Listener/Handler. The proof material in the authentication request is securely relayed to the authentication server, which verifies the supplied information.Credentials
object that is used by all future invocations. The Credentials
object for the user is associated with the Current
object that represents the security context.Figure 3-2 illustrates these steps.
Defining password authentication for a CORBA application includes administration and programming steps. Table 3-2 and Table 3-3 list the administration and programming steps for password authentication. For a detailed description of the administration steps for password authentication, see Configuring Authentication on page 7-1. For a complete description of the programming steps, see Writing a CORBA Application That Implements Security on page 9-1.
The BEA Tuxedo product provides the industry-standard SSL protocol to establish secure communications between client and server applications. When using the SSL protocol, principals use digital certificates to prove their identity to a peer.
The default behavior of the SSL protocol in the CORBA security environment is to have the IIOP Listener/Handler prove its identity to the principal who initiated the SSL connection using digital certificates. The digital certificates are verified to ensure that each of the digital certificates has not been tampered with or expired. If there is a problem with any of the digital certificates in the chain, the SSL connection is terminated. In addition, the issuer of a digital certificate is compared against a list of trusted certificate authorities to verify the digital certificate received from the IIOP Listener/Handler has been signed by a certificate authority that is trusted by the BEA Tuxedo domain.
Like LLE, the SSL protocol can be used with password authentication to provide confidentiality and integrity to communication between the client application and the BEA Tuxedo domain. When using the SSL protocol with password authentication, you are prompted for the password of the IIOP Listener/Handler defined by the SEC_PRINCIPAL_NAME
parameter when you enter the tmloadcf
command.
The SSL protocol works in the following manner:
The initiating application can then use either password or certificate authentication to authenticate itself to the BEA Tuxedo domain.
Figure 3-3 illustrates how the SSL protocol works.
To use the SSL protocol in a CORBA application, you need to install a license that enables the use of the SSL protocol and PKI. For information about installing the license for the security features, see Installing the BEA Tuxedo System.
The implementation of the SSL protocol is flexible enough to fit into most public key infrastructures. The BEA Tuxedo product requires that digital certificates are stored in an LDAP-enabled directory. You can choose any LDAP-enabled directory service. You also need to choose the certificate authority from which to obtain digital certificates and private keys used in a CORBA application. You must have an LDAP-enabled directory service and a certificate authority in place before using the SSL protocol in a CORBA application.
Using the SSL protocol in a CORBA application is primarily an administration process. Table 3-5 lists the administration steps required to set up the infrastructure required to use the SSL protocol and configure the IIOP Listener/Handler for the SSL protocol. For a detailed description of the administration steps, see Managing Public Key Security on page 4-1 and Configuring the SSL Protocol on page 6-1.
Once the administration steps are complete, you can use either password authentication or certificate authentication in your CORBA application. For more information, see Writing a CORBA Application That Implements Security on page 9-1.
Note: | If you are using the BEA CORBA C++ ORB as a server application, the ORB can also be configured to use the SSL protocol. For more information, see Configuring the SSL Protocol on page 6-1. |
If you use the SSL protocol with password authentication, you need to set the SECURITY
parameter in the UBBCONFIG
file to desired level of authentication and if appropriate, configure the Authentication Server (AUTHSRV
). For information about the administration steps for password authentication, see Password Authentication.
Figure 3-4 illustrates the configuration of a CORBA application that uses the SSL protocol.
Certificate authentication requires that each side of an SSL connection proves its identity to the other side of the connection. In the CORBA security environment, the IIOP Listener/Handler presents its digital certificate to the principal who initiated the SSL connection. The initiator then provides a chain of digital certificates that are used by the IIOP Listener/Handler to verify the identity of the initiator.
Once a chain of digital certificates is successfully verified, the IIOP Listener/Handler retrieves the value of the distinguished name from the subject of the digital certificate. The CORBA security environment uses the e-mail address element of the subject's distinguished name as the identity of the principal. The IIOP Listener/Handler uses the identity of the principal to impersonate the principal and establish a security context between the initiating application and the BEA Tuxedo domain.
Once the principal has been authenticated, the principal that initiated the request and the IIOP Listener/Handler agree on a cipher suite that represents the type and strength of encryption that they both support. They also agree on the encryption key and synchronize to start encrypting all subsequent messages.
Figure 3-5 provides a conceptual overview of the certificate authentication.
Commonly, X.509 V3 CA certificates are required to contain the Basic Constraints extension, marked as being from a Certificate Authority (CA), and marked as a critical extension (see IETF RFC 2459). Ensuring that V3 CA certificates protects against non-CA certificates from masquerading as intermediate CA certificates.
For more information, please refer to the following URL:
http://www.ietf.org/rfc/rfc2459.txt
Note: | This default behavior will not check Basic Constraints on X.509 V1 and V2 certificates, as these versions of X.509 certificates do not support certificate extensions. |
There is a mechanism provided to control the level of enforcement that will be performed in order to avoid problems with some customer's applications:
The mechanism is used by setting the value of the environment variable TUX_SSL_ENFORCECONSTRAINTS. The levels of enforcement are as follows:
TUX_SSL_ENFORCECONSTRAINTS=0
TUX_SSL_ENFORCECONSTRAINTS=2
Certificate authentication works in the following manner:
corbaloc://host:port
or corbalocs://host:port
and controls the requirement for protection by setting attributes on the SecurityLevel2::Credentials
object returned as a result of the SecurityLevel2::PrincipalAuthenticator::authenticate
operation.Note: | You can also use the SecurityLevel2::Current::authenticate() method to secure the bootstrapping process and specify that certificate authentication is to be used. |
The security context is established as result of a SecurityLevel2::PrincipalAuthenticator::authenticate()
method.
The IIOP Listener/Handler receives and validates the application's digital certificate as part of the authentication process.
Credentials
object. The Credentials
object for the principal represents the security context for the current thread of execution.To use certificate authentication in a CORBA application, you need to install a license that enables the use of the SSL protocol and PKI. For information about installing the license, see Installing the BEA Tuxedo System.
Using certificate authentication in a CORBA application includes administration and programming steps. Table 3-5 and Table 3-6 list the administration and programming steps for certificate authentication. For a detailed description of the administration steps, see Managing Public Key Security on page 4-1 and Configuring the SSL Protocol on page 6-1.
Figure 3-7 illustrates the configuration of a CORBA application that uses certificate authentication.
Table 3-6 lists the programming steps for using certificate authentication in a CORBA application. For more information, see Writing a CORBA Application That Implements Security on page 9-1.
Write application code that uses the
corbaloc or corbalocs URL address formats of the Bootstrap object. Note that the CommonName in the Distinguished Name of the certificate of the IIOP Listener/Handler must match exactly the host name provided in the URL address format. For more information on the URL address formats, see Using the Bootstrapping Mechanism.
You can also use the CORBA INS bootstrap mechanism to object a reference to a PrincipalAuthenticator object in the BEA Tuxedo domain. For more information about using CORBA INS, see the CORBA Programming Reference.
|
|
The BEA Tuxedo product allows the integration of authentication plug-ins into a CORBA application. The BEA Tuxedo product can accommodate authentication plug-ins using various authentication technologies, including shared-secret password, one-time password, challenge-response, and Kerberos. The authentication interface is based on the generic security service (GSS) application programming interface (API) where applicable and assumes authentication plug-ins have been written to the GSSAPI.
If you chose to use an authentication plug-in, you must configure the authentication plug-in in the registry of the BEA Tuxedo system. For more detail about the registry, see Configuring Security Plug-ins on page 8-1.
For more information about an authentication plug-ins, including installation and configuration procedures, see your BEA account executive.
Authorization allows system administrators to control access to CORBA applications. Specifically, an administrator can use authorization to allow or disallow principals to use resources or services provided by a CORBA application.
The CORBA security environment supports the integration of authorization plug-ins. Authorization decisions are based in part on the user identity represented by an authorization token. Authorization tokens are generated during the authentication process so coordination between the authentication plug-in and the authorization plug-in is required.
If you chose to use an authorization plug-in, you must configure the authorization plug-in the registry of the BEA Tuxedo system. For more detail about the registry, see Configuring Security Plug-ins on page 8-1.
For more information about authorization plug-ins, including installation and configuration procedures, see your BEA account executive.
Auditing provides a means to collect, store, and distribute information about operating requests and their outcomes. Audit-trail records may be used to determine which principals performed, or attempted to perform, actions that violated the configured security policies of a CORBA application. They may also be used to determine which operations were attempted, which ones failed, and which ones successfully completed.
The current implementation of the auditing feature supports the recording of logon failures, impersonation failures, and disallowed operations into the ULOG
file. In the case of disallowed operations, the value of the parameters to the operation are not provided because there is no way to know the order and data types of the parameter for an arbitrary operation. Audit entries for logon and impersonation include the identity of the principal attempting to be authenticated. For information about setting up the ULOG
file, see Setting Up a BEA Tuxedo Application.
You can enhance the auditing capabilities of your CORBA application by using an auditing plug-in. The BEA Tuxedo system will invoke the auditing plug-in at predefined execution points, usually before an operation is attempted and then when potential security violations are detected or when operations are successfully completed. The actions taken to collect, process, protect, and distribute auditing information depend on the capabilities of the auditing plug-in. Care should be taken with the performance impact of audit information collection, especially successful operation audits, which may occur at a high rate.
Auditing decisions are based partly on user identity, which is stored in an auditing token. Because auditing tokens are generated by the authentication plug-in, providers of authentication and auditing plug-ins need to ensure that these plug-ins work together.
The purpose of an auditing request is to record an event. Each auditing plug-in returns one of two responses: success
(the audit succeeded and the event was logged) or failure
(the audit failed and the event was not logged the event). An auditing plug-in is called once before the operation is performed and once after the operation completes.
Multiple implementations of the auditing plug-in can be used in a CORBA application. Using multiple authorization plug-ins causes more than one preoperation and postoperation auditing operation to be performed.
When using multiple auditing plug-ins, all the plug-ins are placed under a single master auditing plug-in. Each subordinate authorization plug-in returns SUCCESS
or FAILURE
. If any plug-in fails the operation, the auditing master plug-in determines the outcome to be FAILURE
. Other error returns are also considered FAILURE
. Otherwise, SUCCESS
is the outcome.
In addition, a BEA Tuxedo system process may call an auditing plug-in when a potential security violation occurs. (Suspicion of a security violation arises when a preoperation or postoperation authorization check fails or when an attack on security is detected.) In response, the auditing plug-in performs a postoperation audit and returns whether the audit succeeded.
The auditing process is somewhat different for users of the auditing feature provided by the BEA Tuxedo product and users of auditing plug-ins. The default auditing feature does not support preoperation audits. If the default auditing feature receives a preoperation audit request, it returns immediately and does nothing.
If you chose to use an auditing plug-in other than the default auditing plug-in, you must configure the auditing plug-in the registry of the BEA Tuxedo system. For more detail about the registry, see Configuring Security Plug-ins on page 8-1.
For more information about auditing plug-ins, including installation and configuration procedures, see your BEA account executive.
The BEA Tuxedo product provides a PKI environment which includes the SSL protocol and the infrastructure needed to use digital certificates in a CORBA application. However, you can use the PKI interfaces to integrate a PKI plug-in that supplies custom message-based digital signature and message-based encryption to your CORBA applications. Table 3-7 describes the PKI interfaces.
The PKI interfaces support the following algorithms:
If you chose to use a PKI plug-in, you must configure the PKI plug-in in the registry of the BEA Tuxedo system. For more detail about the registry, see Configuring Security Plug-ins on page 8-1.
For more information about PKI plug-ins, including installation and configuration procedures, see your BEA account executive.
The following sections answer some of the commonly asked questions about the CORBA security features.
The answer is no. If you are using security interfaces from previous versions of the WebLogic Enterprise product in your CORBA application there is no requirement for you to change your CORBA application. You can leave your current security scheme in place and your existing CORBA application will work with CORBA applications built with BEA Tuxedo 8.0 or later.
For example, if your CORBA application consists of a set of server applications which provide general information to all client applications which connect to them, there is really no need to implement a stronger security scheme. If your CORBA application has a set of server applications which provide information to client applications on an internal network which provides enough security to detect sniffers, you do not need to implement the additional security features.
The answer is yes. You may want to take advantage of the extra security protection provided by the SSL protocol in your existing CORBA application. For example, if you have a CORBA server application which provides stock prices to a specific set of client applications, you can use the SSL protocol to make sure the client applications are connected to the correct CORBA server application and that they are not being routed to a fake CORBA server application with incorrect data. A username and password is sufficient proof material to authenticate the client application. However, by using the SSL protocol, the message request/reply information can be protected as an additional level of security.
The SSL protocol offers CORBA applications the following benefits:
To use the SSL protocol in a CORBA application, set up the infrastructure to use digital certificates, change the command-line options on the ISL server process to use the SSL protocol, and configure a port for secure communications on the IIOP Listener/Handler. If your existing CORBA application uses password authentication, you can use that code with the SSL protocol. If your CORBA C++ client application does not already catch the InvalidDomain
exception when resolving initial references to the Bootstrap object and performing authentication, write code to handle this exception. For more information, see
PKI Plug-ins on page 3-22.
You might be ready to migrate your existing CORBA application to use Internet connections between the CORBA application and Web browsers and commercial Web servers. For example, users of your CORBA application might be shopping over the Internet. The users must be confident that:
In these situations, the SSL protocol and certificate authentication offer CORBA applications the maximum level of protection. In addition to the benefits achieved through the use of the SSL protocol, certificate authentication offers CORBA applications:
For more information, see PKI Plug-ins on page 3-22.