Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	e-docs.beasys.com   |   Site Map   |   Search   |   PDF Files   |   Contact   |   Glossary
WLE Doc Home   |   Security & Related Topics   |   Previous   |   Next   |   Contents   |   Index

This topic includes the following sections:

• WLE Security Features

• Link-Level Encryption

• Username/Password Authentication

• The SSL Protocol

• Certificate-Based Authentication

• Commonly Asked Questions about WLE Security

WLE Security Features

The BEA WebLogic Enterprise (referred to as WLE) product enables you to integrate the following essential security features into your WLE applications:

• Authentication allows the two communicating parties to be certain that they are speaking with someone whom they trust. By using usernames and passwords or digital certificates and public-key technology, a WLE object and the application that invokes a request on the WLE object can each be authenticated to the other.

• Confidentiality is the ability to keep communication secret from parties other than the intended recipient. It is achieved by encrypting all data. The WLE product provides mechanisms that enable two communicating parties to negotiate an algorithm they both support and to agree on the keys with which to encrypt the data.

• Integrity is a guarantee that the data being transferred has not been modified in transit. The same handshake that allows two parties to agree on a method of encryption also provides a means of supplying integrity through the use of shared data integrity secrets. Shared data integrity secrets ensure that when data is received, any modifications made to the data while in transit will be detected. The WLE product provides the security features:

• Link-Level Encryption

• Username/Password authentication

• The SSL protocol

• Certificate-based authentication The remainder of this topic describes how the different security features work in the WLE product.

Link-Level Encryption

Link-level encryption (LLE) is the encryption of messages going across network links between machines in a WLE domain or between WLE domains. The objective of LLE is to ensure confidentiality so that a network-based eavesdropper cannot learn the content of WLE system messages or WLE application-generated messages. LLE is point-to-point, which means that data may be encrypted/decrypted as many times as it flows over network links.

How LLE Works

LLE works in the following way:

1. The system administrator sets a parameter to control the encryption strength.

2. The WLE domain receives the initial connection and starts to negotiate the encryption level to be used between the WLE applications.

3. The two WLE applications agree on the largest common key size supported by both.

4. The configured maximum key size parameter is reduced to agree with the installed software's capabilities. This step must be done at link negotiation time, because at configuration time it may not be possible to verify a particular machine's installed encryption package.

5. The WLE applications exchange messages using the appropriate encryption level.

Figure 1-1 illustrates these steps.

Figure 1-1 How LLE Works

Development Process

The implementation of LLE is an administrative task. The system administrators for each WLE application set parameters in the UBBCONFIG file that control encryption strength. When the two WLE 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.

Username/Password Authentication

The WLE product supports a username/password mechanism to provide authentication to existing WLE applications and to new WLE applications that are not prepared to deploy a full public key infrastructure (PKI). When using Username/Password authentication, the applications that initiate invocations on WLE objects authenticate themselves to the WLE domain using a defined username and password.

The WLE product utilizes a delegated trust authentication model. In this model, initiating applications authenticate to a trusted gateway process. In the WLE product, the trusted gateway process is the IIOP Listener/Handler. As part of successful authentication, a security association, called a security context, is established between the initiating application and the IIOP Listener/Handler that controls access to WLE objects.

Two levels of Username/Password authentication are provided:

• Application password-In this security scenario, the client application authenticates itself to the WLE domain. A user name or client application name, and application password are used to authenticate the client application.

• System authentication-In this security scenario, the client application provides the same information as when using application password authentication and additional authentication data that is verified by a WLE-provided authentication server (AUTHSRV ) before access is granted to client application.

Username/Password authentication is available in both the base WLE product and the WLE Security pack. If you install the WLE Security pack and choose to use Username/Password authentication, the SSL protocol can be used to provide confidentiality to communication between different machines. When using Username/Password authentication, you have the option of using the Tobj::PrincipalAuthenticator::logon() or the SecurityLevel2::PrincipalAuthenticator::authenticate() methods.

How Username/Password Authentication Works

Username/Password authentication works in the following way:

1. The initiating application instantiates the Bootstrap object with any of the URL address formats. For more information about which URL address format to use with the Bootstrap object, see Understanding the Address Formats of the Bootstrap Object.

2. The initiating application obtains credentials for the user. The initiating application must provide proof material to be used by the WLE domain to authenticate the user. This proof material consists of the name of the user and a password.

   • The initiating application creates the security context using a 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.

   • If the verification succeeds, the WLE system constructs a 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.

3. The initiating application invokes a WLE object in the WLE domain using an object reference. The request is packaged into an IIOP request and is forwarded to the IIOP Listener/Handler that associates the request with the previously established security context.

   If the SSL protocol is used to secure the connection for confidentiality and integrity, the data will also be protected from eavesdropping.

4. The IIOP Listener/Handler receives the request from the initiating application.

5. The IIOP Listener/Handler forwards the request, along with the credentials of the initiating application, to the appropriate WLE object.

Figure 1-2 illustrates these steps.

Figure 1-2 How Username/Password Authentication Works

Development Process for Username/Password Authentication

Defining Username/password authentication for a WLE application includes administration and programming steps. Table 1-1 and Table 1-2 list the administration and programming steps for Username/Password authentication. For a detailed description of the administration steps for Username/Password authentication, see Defining Security for a WLE CORBA Application. For a complete description of the programming steps, see Writing a WLE CORBA Application That Implements Security.

Table 1-1 Administration Steps for Username/Password Authentication

Step	Description
1	Set the SECURITY parameter in the UBBCONFIG file to either APP_PW or USER_AUTH .
2	If you defined the SECURITY parameter as USER_AUTH , configure the authentication server (AUTHSRV ) in the UBBCONFIG file.
3	Use the tpusradd and tpgrpadd commands to define lists of authorized users and groups.
4	Use the tmloadcf command to load the UBBCONFIG file. When the UBBCONFIG file is loaded, the system administrator is prompted for a password. The password entered at this time becomes the password for the WLE application.

Table 1-2 Programming Steps for Username/Password Authentication

Step	Description
1	Write application code that uses the Bootstrap object to obtain a reference to the SecurityCurrent object.
2	Write application code that obtains the PrincipalAuthenticator object from the SecurityCurrent object.
3	Write application code that uses the Tobj::PrincipalAuthenticator::logon() or SecurityLevel2::PrincipalAuthenticator::authenticate() operation to establish a security context with the WLE domain.
4	Write application code that prompts the user for the password defined when the UBBCONFIG file is loaded.

The SSL Protocol

The WLE product provides the industry-standard Secure Sockets Layer (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 WLE product is to have the IIOP Listener/Handler prove its identity to the principal who initiated the SSL connection using a digital certificate. The digital certificate is verified to ensure that the certificate has not been tampered with or expired. If there is a problem with the digital certificate in the chain, the SSL connection is terminated. In addition, the issuer of the 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 WLE domain.

Figure 1-3 provides a conceptual overview of the SSL protocol.

Figure 1-3 The SSL Protocol

How the SSL Protocol Works

The SSL protocol works in the following manner:

1. The initiating application instantiates the Bootstrap object with a URL in the form of corbaloc://host:port or corbalocs://host:port.

   If you use the corbaloc://host:port URL address format, the bootstrapping process is unsecure. You can use the authenticate() method of the SecurityLevel2::Current interface and the invocations_options_required() method to secure the bootstrapping process and specify that certificate-based authentication is to be used.

2. The initiating application receives the digital certificate of the principal in this case the IIOP Listener/Handler. The security context is established as result of a Tobj_Bootstrap::resolve_initial_references() or a Tobj::PrincipalAuthenticator::Logon() method. This step is transparent to the user of the application.

3. If the verification succeeds, the WLE system constructs a Credentials object. The Credentials object for the principal represents the security context for the current thread of execution.

4. The initiating application invokes a WLE object in the WLE domain using an object reference.

5. The request is packaged into an IIOP request and is forwarded to the IIOP Listener/Handler that associates the request with the established security context.

   The request is digitally signed and encrypted before it is sent to the IIOP Listener/Handler. The WLE system performs the signing and sealing of requests.

6. The IIOP Listener/Handler receives the request from the initiating application. The digital signature of the request is verified and the request is decrypted.

7. The IIOP Listener/Handler forwards the request to the appropriate WLE object.

Figure 1-4 illustrates these steps.

Figure 1-4 How the SSL Protocol Works in a WLE Application

Requirements for Using the SSL Protocol

To use the SSL protocol in a WLE application, you need to install the WLE Security Pack. Information about installing the WLE Security Pack can be found in the BEA WebLogic Enterprise Installation Guide.

The WLE implementation of the SSL protocol is flexible enough to fit into most public key infrastructures. The WLE product requires that certificates are stored in an LDAP-enabled directory. You can choose any LDAP-enabled directory service. You can also choose the certificate authority from which to obtain certificates and private keys used in a WLE application. You must have an LDAP-enabled directory service and a certificate authority in place before using the SSL protocol in a WLE application.

Development Process for the SSL Protocol

Using the SSL protocol in a WLE application is primarily an administration process. Table 1-4 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 Certificates and Keys and Configuring the WLE Environment for the SSL Protocol.

Once the administration steps are complete, you can use either Username/Password authentication or Certificate authentication in your WLE application. For more information, see Writing a WLE CORBA Application That Implements Security. In addition, you can use the SSL protocol with Enterprise JavaBeans, for more information, see Writing a WLE Enterprise JavaBean that Implements Security.

Note: If you are using the BEA CORBA C++ or CORBA Java ORB as a server application, the ORB can also be configured to use the SSL protocol. For more information, see Configuring the WLE Environment for the SSL Protocol.

Table 1-3 Administration Steps for the SSL Protocol

Step	Description
1	Install the WLE Security pack.
2	Set up an LDAP-enabled directory service.
3	Obtain a certificate and private key for the IIOP Listener/Handler from a certificate authority.
4	Publish the certificates for the IIOP Listener/Handler and the certificate authority in the LDAP-enabled directory service.
5	Define the SEC_PRINCIPAL_NAME , SEC_PRINCIPAL_LOCATION , and SEC_PRINCIPAL_PASSVAR parameters for the ISL server process in the UBBCONFIG file.
6	Define a port for secure communication on the IIOP Listener/Handler using the -s option of the ISL command.
7	Create a Trusted Certificate Authority file (trust_ca.cer) that defines the certificate authorities trusted by the IIOP Listener/Handler.
8	Use the tmloadcf command to load the UBBCONFIG file.
9	Optionally, create a Peer Rules file (peer_val.rul ) for the IIOP Listener/Handler.
10	Optionally, modify the LDAP Search filter file to reflect the directory hierarchy in place in your enterprise.

Figure 1-5 illustrates the configuration of a WLE application that uses the SSL protocol.

Figure 1-5 Configuration for Using the SSL Protocol in a WLE Application

Certificate-Based Authentication

Certificate-based authentication requires that each side of an SSL connection proves its identity to the other side of the connection. In the WLE product, 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 WLE product uses the email 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 WLE 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 1-6 provides a conceptual overview of the certificate-based authentication.

Figure 1-6 Certificate-Based Authentication

How Certificate-based Authentication Works

Certificate-based authentication works in the following manner:

1. The initiating application instantiates the Bootstrap object with a URL in the form of 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-based authentication is to be used.

2. The initiating application obtains the digital certificate and the private key of the principal. Retrieval of this information may require proof material to be supplied to gain access to the principal's private key and certificate. The proof material typically is a pass phrase rather than a password.

   The security context is established as result of a Tobj_Bootstrap::resolve_initial_references() or a Tobj::PrincipalAuthenticator::Logon() method. This step is transparent to the user of the application.

3. If the verification succeeds, the WLE system constructs a Credentials object. The Credentials object for the principal represents the security context for the current thread of execution.

4. The initiating application invokes a WLE object in the WLE domain using an object reference.

5. The request is packaged into an IIOP request and is forwarded to the IIOP Listener/Handler that associates the request with the established security context.

6. The request is digitally signed and encrypted before it is sent to the IIOP Listener/Handler. The WLE system performs the signing and sealing of requests.

7. The IIOP Listener/Handler receives the request from the initiating application. The digital signature of the request is verified and the request is decrypted.

8. The IIOP Listener/Handler maps the principals certificate identity to a TUXEDO user identity.

9. The IIOP Listener/Handler forwards the request, along with the TUXEDO identity of the principal, to the appropriate WLE object.

   Figure 1-7 How Certificate-Based Authentication Works

   

Certificate-based authentication uses the SSL protocol so you need to install the WLE Security Pack. Information about installing the WLE Security Pack can be found in the BEA WebLogic Enterprise Installation Guide. You also need an LDAP-enabled directory. You can choose any LDAP-enabled directory service. You can also choose the certificate authority from which to obtain certificates and private keys used in a WLE application. You must have an LDAP-enabled directory service and a certificate authority in place before using certificate-based authentication in a WLE application.

Development Process for Certificate-Based Authentication

Using certificate-based authentication in a WLE application includes administration and programming steps. Table 1-4 and Table 1-5 list the administration and programming steps for certificate-based authentication. For a detailed description of the administration steps, see Managing Certificates and Keys and Configuring the WLE Environment for the SSL Protocol.

Table 1-4 Administration Steps for Certificate-Based Authentication

Step	Description
1	Install the WLE Security pack.
2	Set up an LDAP-enabled directory service.
3	Obtain a certificate and private key for the IIOP Listener/Handler from a certificate authority.
4	Obtain a certificate and private key for the WLE application from a certificate authority.
5	Store the private key files for the WLE application in the Home directory of the user or in $TUXDIR/udataobj/security/keys .
6	Publish the certificates for the IIOP Listener/Handler, the WLE application, and the certificate authority in the LDAP-enabled directory service.
7	Define the SEC_PRINCIPAL_NAME , SEC_PRINCIPAL_LOCATION , and SEC_PRINCIPAL_PASSVAR for the ISL server process in the UBBCONFIG file.
8	Use the tpusradd command to define the authorized users of your WLE application.
9	Define a port for secure on the IIOP Listener/Handler using the -s option of the ISL command.
10	Enable certificate-based authentication in the IIOP Listener/Handler using the -a option of the ISL command.
11	Create a Trusted Certificate Authority file (trust_ca.cer) that defines the certificate authorities trusted by the IIOP Listener/Handler.
12	Create a Trusted Certificate Authority file (trust_ca.cer) that defines the certificate authorities trusted by the WLE client application.
13	Use the tmloadcf command to load the UBBCONFIG file.
14	Optionally, create a Peer Rules file (peer_val.rul ) for both the WLE client application and the IIOP Listener/Handler.
15	Optionally, modify the LDAP Search filter file to reflect the directory hierarchy in place in your enterprise.

Figure 1-8 illustrates the configuration of a WLE application that uses certificate-based authentication.

Figure 1-8 Configuration for Using Certificate-Based Authentication in a WLE Application

Table 1-5 lists the programming steps for using certificate-based authentication in a WLE application. For more information, see Writing a WLE CORBA Application That Implements Security. In addition, you can use certificate-based authentication with Enterprise JavaBeans, for more information see Writing a WLE Enterprise JavaBean that Implements Security.

Table 1-5 Programming Steps for Certificate-Based Authentication

Step	Description
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.
2	Write application code that uses the authenticate() method of the SecurityLevel2::Current interface to perform authentication. Specify Tobj::CertificateBased for the method argument and the pass phrase for the private key as the auth_data argument for Security::Opaque .

Commonly Asked Questions about WLE Security

The following sections answer some of the commonly asked questions about the WLE security features.

Do I have to Change the Security in an Existing WLE Application?

The answer is no. If you are using security interfaces from previous versions of the WLE product in your WLE application there is no requirement for you to change your WLE application. You can leave your current security scheme in place and your existing WLE application will work with WLE applications built with the WLE 5.0 product.

For example, if your WLE 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 WLE 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 don't need to implement the features in the WLE Security Pack.

Can I Use the SSL Protocol in an Existing WLE Application?

The answer is yes. You may want to take advantage of the extra security protection provided by the SSL protocol in your existing WLE application. For example, if you have a WLE 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 WLE server application and that they are not being routed to a fake WLE 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 username and password will be encrypted adding an additional level of security.

The SSL protocol offers WLE applications the following benefits:

• Protection of the entire conversation including the initial bootstrapping process. The SSL protocol protects against man-in-the-middle attacks, replay attacks, tampering, and sniffing.

• Even if you only use the default settings, the SSL protocol provides signed and sealed protection since the default encryption settings are a minimum of 40 bit by default.

• Client verification of the connected IIOP Listener/Handler using the certificate of the IIOP Listener/Handler. The client application can then apply additional security rules to restrict access to the client application by the IIOP Listener/Handler. This protection also applies to IIOP Listener/Handlers connecting to remote server applications when using callback objects.

To use the SSL protocol in a WLE 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 WLE application uses username/password authentication, you can use that code with the SSL protocol. If your WLE C++ CORBA 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 The SSL Protocol.

Note: The Java implementation of the Tobj_Bootstrap::resolve_initial_references() method does not throw an InvalidDomain exception. When the corbaloc or corbalocs URL address formats are used, the Tobj_Bootstrap::resolve_initial_references() method internally catches the InvalidDomain exception and throws the exception as a COMM_FAILURE . The method functions this way in order to provide backward compatibility.

When Should I Use Mutual Certificate-Based Authentication?

You might be ready to migrate your existing WLE application to use Internet connections between the WLE application and web browsers and commercial web servers. For example, users of your WLE application might be shopping over the internet. The users must be confident that:

• They are in fact communicating with the server at the online store and not an impostor that mimics the store's server to get credit card information.

• The data exchanged between the user of the WLE application and the online store will be unintelligible to network eavesdroppers.

• The data exchanged with the online store will arrive unaltered. An instruction to order $500 worth of merchandise must not accidently or maliciously become a $5000 order.

In these situations, the SSL protocol and certificate-based authentication offer WLE applications the maximum level of protection. In addition to the benefits achieved through the use of the SSL protocol, certificate-based authentication offers WLE applications:

• IIOP Listener/Handler verification of the client application that initiates a request using the certificate of the client application. In addition, the IIOP Listener/Handler can apply additional rules which restrict access to the client application based on the identity established by the certificate. A remote ORB acting as a server application can also be configured to allow mutual authentication and verify the identity of a client application based on a certificate.

• Inside the WLE domain, the client application can still have a TUXEDO username and password. The IIOP Listener/Handler will perform maps the identity defined in a certificate to a TUXEDO username and password thus allowing existing WLE applications to have an identity in native WLE server applications.

For more information, see The SSL Protocol and Certificate-Based Authentication