bea.com | products | dev2dev | support | askBEA |
|
e-docs > WebLogic Platform > WebLogic Integration > B2B Topics > B2B Security > Configuring Security |
B2B Security |
Configuring Security
This topic includes the following sections:
Before you configure B2B security, make sure you have configured your Keystores as described in Configuring the Keystore. For general information about configuring WebLogic Integration, see Basic Configuration Tasks in Administering B2B Integration.
Configuring the SSL Protocol and Mutual Authentication
To configure WebLogic Server to use the SSL protocol and mutual authentication, complete the following steps:
http://download.oracle.com/docs/cd/E13222_01/wls/docs70/secmanage/ssl.html
Figure 4-1 Choosing a Domain
Figure 4-3 Connections Page
Figure 4-4 SSL Configuration Page
Configuring Access Control Lists for WebLogic Integration
The access control list (ACL) for a WebLogic Integration resource determines whether a user or group can access that resource. To define ACLs, you do the following:
For complete information about defining ACLs, see "Defining ACLs in the Compatibility Realm" in Using Compatibility Security in Managing WebLogic Security at the following URL:
http://download.oracle.com/docs/cd/E13222_01/wls/docs70/secmanage/security6.html
For a B2B resource, one or more permissions can be granted.
The sample configuration shipped with WebLogic Integration provides a pre-set ACL for the JDBC connection pool. In this ACL, three permissions are set for the wlcSamplesUser user on this resource: reserve, shrink, and reset.
The following steps provide an example of the procedure you must complete to change the ACL permissions. In this example, we adjust the reset permissions on the JDBC connection pool in the domain WLIdomain:
Figure 4-5 Choosing ACLs in the Navigation Tree
Figure 4-6 ACL for the JDBC Connection Pool
Figure 4-7 ACL Dialog Box
For more information about access control lists, see "Defining ACLs in the Compatibility Realm" in Using Compatibility Security in Managing WebLogic Security at the following URL:
http://download.oracle.com/docs/cd/E13222_01/wls/docs70/secmanage/security6.html
Configuring Security for the WebLogic Integration B2B Engine
The WebLogic Integration repository contains security information about the WebLogic Integration security system and the trading partners that access B2B resources. You can configure repository information either by using the WebLogic Integration B2B Console, or by specifying the information in a data file that you then import into the repository using the Bulk Loader.
Note: Before importing a WebLogic Integration 2.1 or WebLogic Integration 2.1 SP1 repository data file into the WebLogic Integration 7.0 repository, you must change the system-password attribute of the WLC element in the repository data file to reflect the current password of wlisystem. For more information about migrating the repository, see "Step 12. Start and Test Your WebLogic Integration Application" in Migrating WebLogic Integration 2.1 to WebLogic Integration 7.0 in BEA WebLogic Integration Migration Guide.
For the B2B security system, you need to configure the following as required:
To configure these entities in the B2B security system, complete the following steps:
Figure 4-8 WebLogic Integration B2B Console Main Window
Figure 4-10 WebLogic Integration Security Configuration Page
Configuring Trading Partner Security
Configuring trading partner security involves setting the following for each trading partner:
The following subsections describe how to configure trading partner security for each of these components.
Note: If you use the Bulk Loader to import data into the WebLogic Integration repository, the WebLogic Server users that represent each trading partner configured in the repository are not automatically created. You need to create these WebLogic Server users manually. For more information, see Working with the Bulk Loader in Administering B2B Integration.
Configuring Trading Partner Certificates
WebLogic Integration provides a means to configure the following trading partner certificates.
Note the following general rules about configuring trading partner certificates:
The following example shows the java command that starts WebLogic Server for the Hello Partner sample application:
%JAVA_HOME%\bin\java -classic -ms64m -ms64m -classpath %START_WL_CLASSPATH%
-Dbea.home=%BEA_HOME% -Dweblogic.home=%WL_HOME%
-Dweblogic.system.home=%WLC_SAMPLES_HOME% -Dweblogic.Domain=samples
-Dweblogic.management.password=%SYSTEM_PASSWORD%
-Dweblogic.Name=myserver
-Djava.security.policy=%WL_HOME%\lib\weblogic.policy
-DKey.certificate-name.password=%PASSWORD% weblogic.Server
In the preceding example, certificate-name represents the name of the certificate for which a private key password is being specified, and %SYSTEM_PASSWORD% and %PASSWORD% represent values of those two environment variables.
Note: We recommend that you set passwords in environment variables, rather than hard-coding the passwords into scripts, such as startWeblogic. When environment variables are used, the scripts obtain the values for the passwords from the environment in which the scripts run.
To configure trading partner certificates, complete the following steps:
Note: In the instructions that follow, we assume the following:
Figure 4-14 General Configuration Page for Trading Partner
Figure 4-15 Trading Partner Certificates Configuration Page
Figure 4-16 Adding a New Trading Partner Certificate
Notes: When you create a trading partner in WebLogic Integration, a WebLogic Server user is created for that trading partner at run time, with a username that you specify. When you delete a trading partner from the WebLogic Integration repository, however, the corresponding WebLogic Server user is not automatically deleted. When you delete a trading partner, be sure that you also manually delete the corresponding WebLogic Server user.
For a list of resources that you might find helpful in managing WebLogic Integration B2B resources, visit BEA dev2dev Online at the following URL:
http://dev2dev.bea.com/index.jsp
Here you can find links to sites that provide useful utilities, such as tools for manipulating digital certificates and private keys.
Configuring a Secure Transport
When you configure a transport for a trading partner, you bind the trading partner's transport to a transport security protocol. For example, if a trading partner is configured to use SSL certificates, you must bind that trading partner's transport to a transport protocol that uses SSL. When a secure transport is configured, the client certificate is used for outbound SSL. Because WebLogic Integration allows only one client certificate, there is no need to select the client certificate while configuring a secure transport.
To configure a secure transport for a trading partner, complete the following steps:
Figure 4-17 Trading Partner Transport Configuration Page
Configuring a Secure Delivery Channel
When you configure a trading partner's delivery channel, you have the option of making the delivery channel secure by binding it to the secure transport configured in Configuring a Secure Transport.
To configure a secure channel, complete the following steps:
Figure 4-18 Trading Partner Delivery Channels Configuration Page
Configuring a Secure Document Exchange
When you configure the trading partner document exchange, you can associate a document exchange with a business protocol binding that provides digital signature support or message encryption. Digital signature support is available with all the business protocols supported in WebLogic Integration; however, message encryption is available only with the RosettaNet protocol.
To enable digital signature or message encryption support, complete the following steps:
Figure 4-19 Trading Partner Document Exchange Configuration Page
Configuring Message Encryption
As mentioned in Introducing WebLogic Integration B2B Security, the B2B message encryption service encrypts business messages for the business protocols that require it. Currently, message encryption is supported only for the RosettaNet 2.0 protocol.
How WebLogic Integration Message Encryption Works
Data encryption works by using a combination of the sender's certificate, private key, and the recipient's certificate to encode a business message. The message can then be decrypted only by the recipient using the recipient's private key.
Note: The B2B message encryption feature is controlled by licensing (Encryption/Domestic or Encryption/Export), but the decryption of a business message is not. If WebLogic Integration does not have a valid encryption license, the B2B engine disables the encryption service. However, the B2B engine can always decrypt business messages that are received.
The WebLogic Integration message encryption service supports the following algorithms:
The following figure shows how data encryption is performed using the public and private keys.
Figure 4-20 WebLogic Integration Message Encryption Service
Note: To use message encryption, you must have a valid license for using the encryption service. Configuring Message Encryption To configure message encryption for business messages exchanged by trading partners in a RosettaNet 2.0-based conversation definition, complete the following steps:
Notice that when you select a RosettaNet business protocol binding on the Doc Exchange configuration tab, the Encryption box is displayed in the lower left corner of the tab. The following figure shows the Doc Exchange configuration tab, with the Encryption box.
Figure 4-21 Configuration Box for Message Encryption on Doc Exchange Configuration Page
Note: If cipher strength is specified in the repository data file, it is ignored at run time.
Configuring Digital Signatures for Nonrepudiation
Digital signature support (described in detail in Implementing Nonrepudiation) provides a means to prevent anyone or anything from tampering with the contents of a business message, especially when the business message is in transit between two trading partners. Digital signature support is a requirement for nonrepudiation.
If you are implementing nonrepudiation, you need to configure digital signature support in the B2B engine, which you can do by completing the following steps:
When you choose a signature certificate, notice the data displayed in the nonmodifiable fields that are associated with the signature certificate, as shown in the lower right in the following figure.
Figure 4-22 Configuring Nonrepudiation
These nonmodifiable fields are used for the following purposes.
Customizing the WLCCertAuthenticator Class
The WLCCertAuthenticator class is an implementation of the WebLogic Server CertAuthenticator class. The default implementation of the WLCCertAuthenticator class maps the digital certificate of the trading partner to the corresponding trading partner user defined in the WebLogic Integration repository. You may want to extend this functionality to use mutual authentication for users other than trading partners. For example, you may want to modify the class to map a Web browser or Java client to a WebLogic Server user.
The WLCCertAuthenticator class is invoked by WebLogic Server after an SSL connection between the trading partner and WebLogic Server has been established. The class can extract data from a digital certificate to determine the trading partner name that corresponds to the digital certificate.
The following code example, in which the WebLogic default realm for retrieving users is used, shows how the WLCCertAuthenticator class is customized:
public User authenticate(String userName, Certificate[] certs, boolean ssl)
{
String user = null;
// If not using SSL, return
if (ssl == false)
{
return null;
}
// Verify that the certificate is either a c-hub certificate or a trading partner
// certificate, then return the corresponding WLS user.
if ((user = Security.isValidWLCCertificate(certs))!= null)
{
return realm.getUser(user);
}
// Certificate is not a valid WLC certificate.
// Check here for non-WLC certificate and return the corresponding user.
}
Configuring a Certificate Verification Provider Interface
As explained in Trading Partner Certificate Verification, you use a certificate verification provider to validate a trading partner's digital certificate. If you are using a certificate verification provider (CVP), you need to configure it in the B2B Console, using the steps described in this section.
To configure a CVP:
Figure 4-23 WebLogic Integration System Security Configuration Page
Note: You can load a certificate verification provider via the Bulk Loader. For more information, see Working with the Bulk Loader in Administering B2B Integration.
Configuring WebLogic Integration B2B to Use an Outbound HTTP Proxy Server
If you are using WebLogic Integration in a security-sensitive environment, you may want to use WebLogic Integration behind a proxy server. A proxy server allows trading partners to communicate across intranets or the Internet without compromising security. A proxy server is used to:
When proxy servers are configured on the local network, network traffic (SSL and HTTP) is tunneled through the proxy server to the external network. The following figure illustrates how a proxy server might be used in the WebLogic Integration environment.
Figure 4-24 Proxy Server
To configure a proxy server for WebLogic Integration, complete the following steps:
Figure 4-25 Configuration Tabs in the WebLogic Integration B2B Console
Figure 4-26 WebLogic Integration Proxy Server Configuration Page
myproxy.mycompany.com.
permission java.util.PropertyPermission "ssl.proxyHost", "read, write";
permission java.util.PropertyPermission "ssl.proxyPort", "read, write";
Configuring WebLogic Integration with a Web Server and a WebLogic Proxy Plug-In
You can configure WebLogic Integration with a Web server, such as an Apache server, that is programmed to service business messages from a remote trading partner. A Web server can provide the following services:
The Web server uses the WebLogic proxy plug-in, which you can configure to provide the following services:
The following figure shows the topology of an environment that uses a Web server, the WebLogic proxy plug-in, and WebLogic Integration.
Figure 4-27 Using a Web Server and the WebLogic Proxy Plug-In
Notes: Even though the proxy plug-in uses HTTP, you must configure WebLogic Integration to use the HTTPS protocol when using the proxy plug-in to forward business messages.
If a trading partner in a conversation uses Microsoft IIS as a proxy server, all the certificates used in the conversation must be trusted by a well-known Certificate Authority, such as Verisign or Entrust. The use of self-signed certificates will cause a request passed through the IIS proxy server to fail. This is a restriction in IIS, not WebLogic Integration.
Configuring the Web Server
To configure the Web server, see Configuring WebLogic Server Web Components in the BEA WebLogic Server Administration Guide at the following URL:
http://download.oracle.com/docs/cd/E13222_01/wls/docs70/adminguide/web_server.html
The following code example provides the segment of httpd.conf (for an Apache server) needed to configure the proxy plug-in:
# LoadModule foo_module libexec/mod_foo.so
LoadModule weblogic_module libexec/mod_wl_ssl.<suffix>
<Location /weblogic>
SetHandler weblogic-handler
PathTrim /weblogic
WebLogicHost myhost
WebLogicPort 80
</Location>
WebLogic Server User Identity for the Trading Partner
The WebLogic Server user identity is optional when you configure the remote trading partner. If a particular WebLogic Integration deployment has stringent security requirements, we recommend the following:
Configuring Business Process Management Access to the WebLogic Integration Repository
If you plan to use the business process management (BPM) functionality provided by WebLogic Integration, you need to make sure that BPM users can share access to the WebLogic Integration repository. To support such access, you need to configure BPM with permissions for using the repository: add the WebLogic Server group wlpiUsers to the ACL for the JDBC connection pool used by the WebLogic Integration repository.
In addition, if a user of the WebLogic Integration Studio or Worklist utility needs access to workflow templates stored in the WebLogic Integration repository, you need to add that user to the appropriate ACLs for the WebLogic Server administration MBeans. To do so, specify the following ACLs on the WebLogic Server MBeans for the user. In these settings, replace <user> with the name of the BPM user:
acl.access.weblogic.admin.mbean.MBeanHome=<user>
acl.lookup.weblogic.admin.mbean.MBeanHome=<user>
For information about configuring ACLs for B2B resources, see Configuring Access Control Lists for WebLogic Integration.
Configuring Server-Side Authentication
By default, WebLogic Integration uses two-way SSL authentication. You might want to use server-side authentication, however, if you do not want to require certificate-based authentication among your trading partners.
To configure server-side authentication, complete the following steps:
c:\bea\user_projects\domain