The WebLogic Enterprise Security Features

 

This topic includes the following sections:

• Authentication

• Authorization

• Auditing

• Link-Level Encryption

• The SSL Protocol

• Single Sign-On

• Commonly Asked Questions About the WebLogic Enterprise Security Features

 

---

Authentication

In WebLogic Enterprise product, authentication provides a verified identity to be established for the client application. The WebLogic Enterprise product supports username/password and certificate-based authentication. In addition, a plug-in is provided for authentication so that Privilege Attribute Certificates (PACs) or Kerberos tickets can be used for authentication in the WebLogic Enterprise environment. The following sections describe the different types of authentication and how they are implemented.

Using Username/Password Authentication

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

Two levels of Username/Password authentication are provided:

• Application password-in this security scenario, the client application authenticates itself to the WLE domain. An application password is used to authenticate the client application.

• System authentication-in this security scenario, the client application provides a username or client application name and a password that is verified by a WebLogic Enterprise-provided authentication server (AUTHSRV) before access is granted to client application.

Username/Password authentication is available in both the base WebLogic Enterprise product and the WebLogic Enterprise Security Pack. If you install the WebLogic Enterprise Security Pack and choose to use username/password authentication, the SSL protocol can be used to provide confidentiality to communication between client applications. When using Username/Password authentication, you have the option of using the Tobj::PrincipalAuthenticator::logon() or the SecurityLevel2::PrincipalAuthenticator::authenticate() methods in your client application.

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" on page 10-2.

2. The initiating application obtains credentials for the user. The initiating application must provide proof material to be used by the WebLogic Enterprise 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 WebLogic Enterprise 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 WebLogic Enterprise object in the WebLogic Enterprise 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 WebLogic Enterprise object.

Figure 3-1 illustrates these steps.

Figure 3-1 How Username/Password Authentication Works

Development Process for Username/Password Authentication

Defining Username/Password authentication for a WebLogic Enterprise application includes administration and programming steps. Table 3-1 and Table 3-2 list the administration and programming steps for Username/Password authentication. For a detailed description of the administration steps for Username/Password authentication, see "Configuring Authentication" on page 7-1. For a complete description of the programming steps, see "Writing a WebLogic Enterprise CORBA Application that Implements Security" on page 10-1.

Table 3-1 Administration Steps for Username/Password Authentication

Step	Description
1	Set the SECURITY parameter in the UBBCONFIG file to APP_PW, USER_AUTH, ACL, or MANDATORY_ACL.
2	If you defined the SECURITY parameter as USER_AUTH, ACL, or MANDATORY_ACL, configure the authentication server (AUTHSRV) in the UBBCONFIG file.
3	Use the tpusradd and tpgrpadd commands to define lists of authorized users and groups including the IIOP Listener/Handler.
4	Define the SEC_PRINCIPAL_NAME and SEC_PRINCIPAL_PASSVAR for the ISL server process in the UBBCONFIG file.
5	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 WebLogic Enterprise application.

Table 3-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 WebLogic Enterprise domain.
4	Write application code that prompts the user for the password defined when the UBBCONFIG file is loaded.

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 WebLogic Enterprise 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 WebLogic Enterprise product 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 WebLogic Enterprise 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-2 provides a conceptual overview of the certificate-based authentication.

Figure 3-2 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 certificates 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 SecurityLevel2::PrincipalAuthenticator::authenticate() method. This step is transparent to the user of the application.

3. If the verification succeeds, the WebLogic Enterprise 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 WebLogic Enterprise object in the WebLogic Enterprise 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 WebLogic Enterprise system performs the signing and sealing of requests.

7. The IIOP Listener/Handler receives the request from the initiating application. The request is decrypted.

8. The IIOP Listener/Handler retrieves the email component of the subjectDN of the principal's and uses that as the identity of the user.

9. The IIOP Listener/Handler forwards the request, along with the associated tokens of the principal, to the appropriate WebLogic Enterprise object.

   Figure 3-3 How Certificate-based Authentication Works

   

Requirements for Using Certificate-based Authentication

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

Development Process for Certificate-based Authentication

Using certificate-based authentication in a WebLogic Enterprise application includes administration and programming steps. Table 3-3 and Table 3-4 list the administration and programming steps for certificate-based 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.

Table 3-3 Administration Steps for Certificate-based
Authentication

Step	Description
1	Install the WebLogic Enterprise Security Pack.
2	Set up an LDAP-enabled directory service.
3	Obtain digital certificates and a private key for the IIOP Listener/Handler from a certificate authority.
4	Obtain digital certificates and a private key for each of the WebLogic Enterprise client applications from a certificate authority.
5	Store the private key files for the WebLogic Enterprise client applications and the IIOP Listener/Handler in the Home directory of the user or in $TUXDIR/udataobj/security/keys.
6	Publish the certificates for the IIOP Listener/Handler, the WebLogic Enterprise 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 and tpgrpadd commands to define the authorized users and groups of your WebLogic Enterprise application.
9	Define a port for SSL communication 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 WebLogic Enterprise 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 WebLogic Enterprise 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 3-4 illustrates the configuration of a WebLogic Enterprise application that uses certificate-based authentication.

Figure 3-4 Configuration for Using Certificate-based Authentication in a WebLogic Enterprise Application

Table 3-4 lists the programming steps for using certificate-based authentication in a WebLogic Enterprise application. For more information, see "Writing a WebLogic Enterprise CORBA Application that Implements Security" on page 10-1. In addition, you can use certificate-based authentication with Enterprise JavaBeans (EJBs), for more information see "Writing a WebLogic Enterprise Enterprise JavaBean That Implements Security" on page 12-1.

Table 3-4 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. For more information on the URL address formats, see Understanding the Address Formats of the Bootstrap Object.
2	Write application code that uses the authenticate() method of the SecurityLevel2::PrincipalAuthenticator 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.

Using an Authentication Plug-in

The WebLogic Enterprise product allows the integration of authentication plug-ins into a WebLogic Enterprise application. The WebLogic Enterprise 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 WebLogic Enterprise system. For more detail about the registry, see "Configuring Security Plug-Ins" on page 9-1.

For more information about an authentication plug-ins, including installation and configuration procedures, see your BEA account executive.

 

---

Authorization

Authorization allows system administrators to control access to WebLogic Enterprise applications. Specifically, an administrator can use authorization to allow or disallow principals to use resources or services provided by a WebLogic Enterprise application.

The WebLogic Enterprise product 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.

The authorization plug-in is called for a given client request twice, once when the request is received and once before the reply is returned.

• The preoperation authorization check determines if a certain operation should be permitted or not. The check allows an authorization plug-in to examine the operation, the authorization token, and the data associated with the authorization token. The associated data might be modified and/or saved for the postoperation check.

• The postoperation authorization check determines if an operation should be permitted or not and is based on the analysis of the output data. The postoperation authorization check allows an authorization plug-on to examine the operation, the authorization token, and the associated data.

  Postoperation checking is very useful in rule-based security models. For example, suppose a user is authorized for access to Confidential documents but performs an operation that retrieves a Top Secret document. The document's classification label is not easily determined until after it has been retrieved. In this case, the postoperation authorization check is an effective way to either deny the operation.

Multiple implementations of an authorization plug-in can be used in a WebLogic Enterprise application. Using multiple authorization plug-ins causes more than one preoperation and postoperation authorization check to be performed. A voting scheme is used to determine the result of the authorization checks.

When using multiple authorization plug-ins, all the plug-ins are placed under a single master authorization plug-in. Each subordinate authorization plug-in votes PERMIT, DENY, or ABSTAIN on the client request. The ABSTAIN return value is necessary for authorization plug-in developers to gracefully handle unexpected situations that are not understood (such as new operation names that might be added in the future).

The rules for result determination are as follows:

1. If all authorization plug-ins permit, the operation is okd.

2. If any authorization plug-in denies, the operation is denied.

3. If no authorization plug-in denies and all plug-ins do not permit:

   • If the SECURITY parameter in the UBBCONFIG file is MANDATORY_ACL, the operation is denied.

   • If the SECURITY parameter in the UBBCONFIG file is ACL, the operation is allowed.

   • If the SECURITY parameter in the UBBCONFIG file is NONE, APP_PW or USER_AUTH, no authorization checked is performed. This occurs because it is not possible to perform authorization checks without having an authenticated client identity.

If you chose to use an authorization plug-in, you must configure the authorization plug-in the registry of the WebLogic Enterprise system. For more detail about the registry, see "Configuring Security Plug-Ins" on page 9-1.

For more information about authorization plug-ins, including installation and configuration procedures, see your BEA account executive.

 

---

Auditing

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 WebLogic Enterprise 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 Monitoring Log Files in the Administration Guide.

You can enhance the auditing capabilities of your WebLogic Enterprise application by using an auditing plug-in. The WebLogic Enterprise 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.

• The preoperation audit allows the auditing of both attempts to call an operation, and also allows storage of input data for the postoperation check.

• The postoperation audit reports the status of the completion of an operation. For failure status, the postoperation audit is called to report a potential security violation. Usually this type of report is issued when a preoperation or postoperation authorization check fails or when some other potential security attack is detected.

Multiple implementations of the auditing plug-in can be used in a WebLogic Enterprise 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 WebLogic Enterprise 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 WebLogic Enterprise 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 WebLogic Enterprise system. For more detail about the registry, see "Configuring Security Plug-Ins" on page 9-1.

For more information about auditing plug-ins, including installation and configuration procedures, see your BEA account executive.

 

---

Link-Level Encryption

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 WebLogic Enterprise system messages or WebLogic Enterprise 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 WebLogic Enterprise 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 on the following types of network links:

• BEA Tuxedo Workstation client to Workstation Handler (WSH)

• Bridge-to-bridge (machine to machine in a WebLogic Enterprise domain)

• Administrative utility (such as tmboot or tmshutdown) to tlisten

• WebLogic Enterprise domain gateway to WebLogic Enterprise domain

  Note: LLE cannot be used to protect connections between remote WebLogic Enterprise client applications and the IIOP Listener/Handler.

There are three levels of LLE security: 0-bit (no encryption), 56-bit (International), and 128-bit (United States and Canada). The International LLE version allows 0-bit and 56-bit encryption. The United States and Canada LLE version allows 0, 56, and 128-bit encryption.

How LLE Works

LLE works in the following way:

1. The system administrator sets parameters for any processes that want to use LLE to control the encryption strength.

   • The first configuration parameter is the minimum encryption level that a process will accept. It is expressed as a key length: 0, 56, or 128 bits.

   • The second configuration parameter is the maximum encryption level a process can support. It also is expressed as a key length: 0, 56, or 128 bits.

     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.

2. An initiator process begins the communication session.

3. A target process receives the initial connection and starts to negotiate the encryption level to be used by the two processes to communicate.

4. The two processes agree on the largest common key size supported by both.

5. 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.

6. The processes exchange messages using the appropriate encryption level.

Figure 3-5 illustrates these steps.

Figure 3-5 How LLE Works

Encryption Key Size Negotiation

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.

1. Each process identifies its own min-max values.

2. Together, the two processes find the largest key size supported by both.

Determining min-max Values

When either of the two processes starts up, the WebLogic Enterprise 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 WebLogic Enterprise system then proceeds as follows:

• If the configured min-max values accommodate the installed LLE version, then the local software assigns those values as the min-max values for the process.

• If the configured min-max values do not accommodate the installed LLE version, for example, if the International 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.

• If there are no 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 United States and Canada LLE version.

Finding a Common Key Size

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-5 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.

Table 3-5 Interprocess Negotiation Results

	(0, 0)	(0, 56)	(0, 128)	(56, 56)	(56, 128)	(128, 128)
(0, 0)	0	0	0	ERROR	ERROR	ERROR
(0, 56)	0	56	56	56	56	ERROR
(0, 128)	0	56	128	56	128	128
(56, 56)	ERROR	56	56	56	56	ERROR
(56, 128)	ERROR	56	128	56	128	128
(128, 128)	ERROR	ERROR	128	ERROR	128	128

WSL/WSH Connection Timeout During Initialization

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).

Development Process

LLE is available in the base WebLogic Enterprise product. The implementation of LLE is an administrative task. The system administrators for each WebLogic Enterprise application set min-max values in the UBBCONFIG file that control encryption strength. When the two WebLogic Enterprise 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 SSL Protocol

The WebLogic Enterprise 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 WebLogic Enterprise product 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 WebLogic Enterprise domain.

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

Figure 3-6 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::PrincipalAuthenticator 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 certificates 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 WebLogic Enterprise 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 WebLogic Enterprise object in the WebLogic Enterprise 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/or encrypted before it is sent to the IIOP Listener/Handler. The WebLogic Enterprise system performs the signing and sealing of requests.

6. The IIOP Listener/Handler receives the request from the initiating application. The request is decrypted.

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

Figure 3-7 illustrates these steps.

Figure 3-7 How the SSL Protocol Works in a WebLogic Enterprise Application

Requirements for Using the SSL Protocol

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

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

Development Process for the SSL Protocol

Using the SSL protocol in a WebLogic Enterprise application is primarily an administration process. Table 3-3 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 Username/Password authentication or certificate-based authentication in your WebLogic Enterprise application. For more information, see "Writing a WebLogic Enterprise CORBA Application that Implements Security" on page 10-1. In addition, you can use the SSL protocol with Enterprise JavaBeans, for more information, see "Writing a WebLogic Enterprise Enterprise JavaBean That Implements Security" on page 12-1.

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 SSL Protocol" on page 6-1.

Table 3-6 Administration Steps for the SSL Protocol

Step	Description
1	Install the WebLogic Enterprise Security Pack.
2	Set up an LDAP-enabled directory service.
3	Obtain a digital certificate and private key for the IIOP Listener/Handler from a certificate authority.
4	Publish the digital 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 3-8 illustrates the configuration of a WebLogic Enterprise application that uses the SSL protocol.

Figure 3-8 Configuration for Using the SSL Protocol in a WebLogic Enterprise Application

 

---

Single Sign-On

Single sign-on allows authenticated principals in a WebLogic Server realm to make secure requests on CORBA objects or EJBs in the WebLogic Enterprise domain. Single sign-on is only supported over the connection pool provided by WebLogic Enterprise Connectivity and only if the connection pool has established a trust relationship with the WebLogic Enterprise environment. The trust relationship of the pool can be established in one of the following ways:

• With username/password authentication. In this scenario, the WebLogic Server principal is authenticated but the request between the WebLogic Server realm and the WebLogic Enterprise domain is unprotected.

• With username/password authentication and the SSL protocol. In this scenario, the SSL protocol is used to protect the integrity and confidentiality of the request.

• With the SSL protocol and certificate-based authentication. This is the most secure scenario, however, it requires that both the WebLogic Server application and the WebLogic Enterprise application implement public key security.

Configuring Single Sign-on describes how to implement each of the Single sign-on options.

 

---

PKI Plug-Ins

The WebLogic Enterprise product provides a PKI environment which includes the SSL protocol and the infrastructure needed to use digital certificates. 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 WebLogic Enterprise applications. Table 3-7 describes the PKI interfaces.

Table 3-7 PKI Interfaces

PKI Interface	Description
Public key initialization	Allows public key software to open public and private keys. For example, gateway processes may need to have access to a specific private key in order to decrypt messages before routing them.
Key management	Allows public key software to manage and use public and private keys. Note that message digests and session keys are encrypted and decrypted using this interface, but no bulk data encryption is performed using public key cryptography. Bulk data encryption is performed using symmetric key cryptography.
Certificate lookup	Allows public key software to retrieve X.509v3 digital certificates for a given principal. Digital certificates may be stored using any appropriate certificate repository, such as Lightweight Directory Access Protocol (LDAP).
Certificate parsing	Allows public key software to associate a simple principal name with an X.509v3 digital certificate. The parser analyzes a digital certificate to generate a principal name to be associated with the digital certificate.
Certificate validation	Allows public key software to validate an X.509v3 digital certificate in accordance with specific business logic.
Proof material mapping	Allows public key software to access the proof materials needed to open keys, provide authorization tokens, and provide auditing tokens.

The PKI interfaces support the following algorithms:

• Public key algorithms: Rivest, Shamir, and Adelman (RSA) and Digital Signature Algorithm (DSA)

• Symmetric key algorithms:

  • Data Encryption Standard for Cipher Block Chaining (DES-CBC)

  • Two-key triple-DES

  • Rivest's Cipher 4 (RC4)

• Message digest algorithms:

  • Message Digest 5 (MD5)

  • Secure Hash Algorithm 1 (SHA-1)

If you chose to use a PKI plug-in, you must configure the PKI plug-in the registry of the WebLogic Enterprise system. For more detail about the registry, see "Configuring Security Plug-Ins" on page 9-1.

For more information about PKI plug-ins, including installation and configuration procedures, see your BEA account executive.

 

---

Commonly Asked Questions About the WebLogic Enterprise Security Features

The following sections answer some of the commonly asked questions about the WebLogic Enterprise Security features.

Do I Have to Change the Security in an Existing WebLogic Enterprise Application?

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

For example, if your WebLogic Enterprise 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 WebLogic Enterprise 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 features in the WebLogic Enterprise Security Pack.

Can I Use the SSL Protocol in an Existing WebLogic Enterprise Application?

The answer is yes. You may want to take advantage of the extra security protection provided by the SSL protocol in your existing WebLogic Enterprise application. For example, if you have a WebLogic Enterprise 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 WebLogic Enterprise server application and that they are not being routed to a fake WebLogic Enterprise 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 WebLogic Enterprise 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 56 bit by default.

• Client verification of the connected IIOP Listener/Handler using the digital 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 WebLogic Enterprise 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 WebLogic Enterprise application uses Username/Password authentication, you can use that code with the SSL protocol. If your WebLogic Enterprise 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" on page 3-21.

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 Certificate-based Authentication?

You might be ready to migrate your existing WebLogic Enterprise application to use Internet connections between the WebLogic Enterprise application and web browsers and commercial web servers. For example, users of your WebLogic Enterprise 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 WebLogic Enterprise 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 WebLogic Enterprise applications the maximum level of protection. In addition to the benefits achieved through the use of the SSL protocol, certificate-based authentication offers WebLogic Enterprise applications:

• IIOP Listener/Handler verification of the client application that initiates a request using the digital 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 digital 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 digital certificate.

• Inside the WebLogic Enterprise domain, the client application can still have a BEA Tuxedo username and password. The IIOP Listener/Handler maps the identity defined in a digital certificate to a BEA Tuxedo username and password thus allowing existing WebLogic Enterprise applications to have an identity in native WebLogic Enterprise server applications.

For more information, see "The SSL Protocol" on page 3-21.