Using WebLogic Integration Security

The following sections describe how to set up and manage security for WebLogic Integration solution deployments:

• Overview of WebLogic Integration Security

• Considerations for Configuring Security

• Setting Up a Secure Deployment

Before you proceed with the remainder of this topic, see Introducing WebLogic Platform 7.0 Security, which is available at the following URL:

http://download.oracle.com/docs/cd/E13196_01/platform/docs70/secintro/index.html

This document provides an overview of the security features of the entire WebLogic Platform, and provides important notes about managing security when using WebLogic Integration with other WebLogic Platform components.

 

---

Overview of WebLogic Integration Security

The foundation of every secure deployment of a WebLogic Integration solution is the set of security features provided by WebLogic Server. Therefore, after you configure security for the underlying WebLogic Server layer of your environment, you need to configure and manage security for those WebLogic Server entities that are specific to WebLogic Integration:

• WebLogic Integration system user, wlisystem

• Users of the BPM engine and WebLogic Integration Studio, and the groups to which they belong

• Trading partners for which security management is particularly important because trading partners are required to produce digital certificates for sending and receiving business messages in a secure environment

• Application views

As the security manager for your environment, you need to focus your efforts on a set of predefined principals and resources that are created along with a WebLogic Integration domain.

This introduction presents the following topics to give you a high-level view of WebLogic Integration security:

• Security and WebLogic Integration Domains

• WebLogic Server Security Principals and Resources Used in WebLogic Integration

Note: For a secure deployment, avoid running WebLogic Integration in the same WebLogic Server instance as any applications for which security is not provided. Internal WebLogic Integration API calls are not protected from such collocated applications.

Security and WebLogic Integration Domains

When you create a WebLogic Integration domain using the BEA Configuration Wizard, the domain is configured, by default, to use compatibility security. Compatibility security enables a domain to do the following:

• Use existing stores of users and groups to authenticate WebLogic Server principals

• Use access control lists (ACLs) to protect WebLogic Integration resources

By default, all WebLogic Integration users, groups, and ACLs are stored in a security realm known as the compatibility realm.

Note: A typical installation of WebLogic Integration includes WebLogic Server and WebLogic Workshop components. By default, the Configuration Wizard configures WebLogic Integration security to use compatibility security and allocates the WebLogic Server 6.x File realm for storing users and groups. The File realm is used in all WebLogic Integration samples. The WebLogic Server and WebLogic Workshop samples are based on a security configuration that is, in turn, based on an embedded LDAP server, which WebLogic Integration does not support in this release. Therefore, the samples delivered with WebLogic Server and WebLogic Workshop may not work with the default configuration for the WebLogic Integration samples.

For more information about the BEA Configuration Wizard, see Using the Configuration Wizard, which is available at the following URL:

http://download.oracle.com/docs/cd/E13196_01/platform/docs70/confgwiz/index.html

WebLogic Server Security Principals and Resources Used in WebLogic Integration

When you create a WebLogic Integration domain via the Configuration Wizard, the following WebLogic Server principals and resources are predefined:

• wlisystem—WebLogic Integration system user that functions on behalf of a trading partner after the trading partner is authenticated and authorized to use WebLogic Integration resources.

• wlpiUsers—Business Process Management users group that has access to BPM resources, such as the WebLogic Integration Studio and the BPM engine.

• Set of BPM groups—Each member of the wlpiUsers group is a member of one or more of these groups. Membership in a group determines the set of tasks that can be performed by a principal. Each group represents an ACL.

• wliPool—JDBC connection pool for the WebLogic Integration repository.

• ServletFilter—Resource that is used transparently by trading partners to access B2B resources.

The following diagram provides an overview of the WebLogic Server security principals used in WebLogic Integration.

Figure 5-1 WebLogic Server Security Principals Used in WebLogic Integration

 

For example, during the course of a B2B-based business operation, the WebLogic Server principals may function as follows:

• When started via an event (XML, application integration, or B2B integration), a workflow runs as wlisystem.

• When started via a manual task start, a workflow runs as the security principal associated with the Worklist client.

• An application integration service runs as the security principal configured for the application view.

• When a message is received from a trading partner, the B2B engine momentarily switches to the WebLogic Server principal associated with the client-side certificate for the trading partner. Then it switches to the wlisystem principal before sending the message to the BPM event queue. For more information about B2B integration security, see Implementing Security with B2B Integration.

• When the J2EE-CA adapter receives a request, it maps the caller's security principal to one that is appropriate for the EIS system. For more information, see "Deprecated Security Principal Map Mechanism" in Programming the WebLogic J2EE Connector Architecture in the WebLogic Server documentation set, at the following URL:

  http://download.oracle.com/docs/cd/E13222_01/wls/docs70/jconnector/security.html

 

---

Considerations for Configuring Security

Before you configure the security for your WebLogic Integration domain, consider the following:

• About Digital Certificates

• Using the Secure Sockets Layer (SSL) Protocol

• Using an Outbound Proxy Server or Proxy Plug-In

• Using a Firewall or NonWebLogic Server Proxy Server

The following sections present a high-level discussion of these considerations and describe how they affect your WebLogic Integration security configuration.

About Digital Certificates

Digital certificates are electronic documents used to identify principals and objects as unique entities over networks such as the Internet. A digital certificate securely binds the identity of a user or object, as verified by a trusted third party known as a certificate authority, to a particular public key. The combination of the public key and the private key provides a unique identity for the owner of the digital certificate.

When you set up a WebLogic Integration environment as the foundation of your interenterprise commerce, using the B2B capabilities, you need to obtain and configure a specific set of digital certificates and keys. This set includes the following:

• Server certificate—Required for SSL for the WebLogic Server instance on the local machine.

• Root Certificate Authority—Trusted third-party organization or company that is willing to vouch for the identities of those to whom it issues digital certificates and public keys. Verisign and Baltimore are examples of CAs.

• Trading partner certificates—Required for each local and remote trading partner that is involved in B2B collaborations. These certificates include the client certificate; they may also include encryption and signature certificates, as well. They are used for authentication, authorization, signature support, and message encryption.

Digital Certificate Formats

Make sure that the formats and packaging standards of your digital certificates are compatible with WebLogic Server. Digital certificates have various encoding schemes, including the following:

• Privacy Enhanced Mail (PEM)

• Definite Encoding Rules (DER)

• Public Key Cryptography Standards 7 and 12 (PKCS7 and PKCS12)

The public key infrastructure (PKI) in WebLogic Server recognizes digital certificates that comply with either versions 1 and 3 of X.509, X.509v1 and X.509v3. We recommend obtaining digital certificates from a certificate authority, such as Verisign or Entrust.

Note: 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.

For more details, see Configuring Security in Implementing Security with B2B Integration.

Using the Secure Sockets Layer (SSL) Protocol

The SSL protocol provides secure connections by supporting two functions:

• It enables each of two applications linked through a network connection to authenticate the other's identity

• It encrypts the data exchanged between the applications.

An SSL connection begins with a handshake during which the applications exchange digital certificates, agree on the encryption algorithms to be used, and generate encryption keys that are then used for the remainder of the session.

If you are using SSL for trading partner authentication and authorization, which we strongly recommend for B2B collaborations, you need to configure the following:

• SSL for each machine in your WebLogic Integration domain. For information about how to do this, see "Configuring the SSL Protocol and Mutual Authentication" in Configuring Security in Implementing Security with B2B Integration.

• Set of digital certificates and private keys for each trading partner

• Server certificate for each machine in the WebLogic Integration domain

• Certificate for the root Certificate Authority (CA)

  For more information about configuring certificates, see Configuring Security in Implementing Security with B2B Integration.

Not required by SSL, but strongly recommended, is the creation and use of keystores for storing all the certificates and keys used in your WebLogic Integration domain. WebLogic Server provides a utility called the WebLogic Keystore provider based on the reference Keystore implementation supplied by Sun Microsystems in the Java Development Kit.

The WebLogic Keystore provider is based on the standard JKS keystore type, which implements the keystore as a file. For this release of WebLogic Server, JKS is the only keystore provider available. A keystore configured with the WebLogic Keystore provides protects each private key with an individual password. Two keystore files are associated with the WebLogic Keystore provider: One holds the CA certificates used by SSL to verify client certificates; the other holds users' private keys. WebLogic Server retrieves a private key from this keystore to initialize SSL.

For more information about setting up keystores for your WebLogic Integration domain, see Configuring the Keystore in Implementing Security with B2B Integration.

Using an Outbound Proxy Server or Proxy Plug-In

This section discusses the implications of using either an outbound proxy server or the WebLogic proxy plug-in.

Using an Outbound Proxy Server

A proxy server allows trading partners to communicate across intranets or the Internet without compromising security. If you are using WebLogic Integration in a security-sensitive environment, you may want to use WebLogic Integration behind a proxy server. Specifically, a proxy server is used to:

• Hide, from external hackers, the local network addresses of the WebLogic Server instances that host WebLogic Integration

• Restrict access to the external network

• Monitor external network access to the local instances of WebLogic Server that host WebLogic Integration

When proxy servers are configured on the local network, network traffic (sent with the SSL and HTTP protocols) is tunneled through the proxy server to the external network.

If an outbound proxy server is used in your environment, be careful when specifying the transport URI endpoints for the local trading partner. If you are using an HTTPS proxy, then you need to specify the ssl.ProxyHost and ssl.ProxyPort Java system properties. For details, see "Configuring WebLogic Integration B2B to Use an Outbound HTTP Proxy Server" in Configuring Security in Implementing Security with B2B Integration.

Using a Web Server with the WebLogic Proxy Plug-In

As an alternative to using an outbound proxy server, you may want to configure WebLogic Integration with a Web server, such as an Apache server, that is programmed to handle business messages from a remote trading partner. The Web server can provide the following services:

• Receive business messages from a remote trading partner

• Authenticate digital certificates from the trading partner

The Web server then uses the WebLogic proxy plug-in, which you can configure to provide the following services:

• Forwarding of business messages received by the Web server to WebLogic Integration, which is running inside a secure internal network.

• Extraction of the remote trading partner certificate from the Web server and delivery of it to WebLogic Server for authentication. WebLogic Integration can then authenticate the trading partner certificate and business message.

To configure the WebLogic proxy plug-in, consider the following:

• Make sure you configure the proxy server with the WebLogic proxy plug-in to direct requests to WebLogic Server.

• Decide which protocol you want to use for the network connection between the proxy server and the WebLogic Integration domain. The default protocol is HTTP. Configure the proxy plug-in to use one-way SSL only if you prefer to use SSL.

• When configuring the transport for remote trading partners, specify the remote URI endpoint with the HTTPS protocol, even though the HTTP protocol is used in the network connection between the WebLogic proxy plug-in and the WebLogic Integration domain.

• When relaying a business message from one trading partner to another, some proxy servers include only the leaf certificate, instead of the entire CA certificate chain. In such instances, trading partner authentication may fail. To prevent such failures, we recommend you specify the leaf certificate as the trusted CA certificate. (For more information about leaf certificates, see "Certificate Authority" in Introducing WebLogic Integration B2B Security in Implementing Security with B2B Integration.)

• If the local trading partner site uses a Web server configured with a WebLogic proxy plug-in, then you can specify the trading partner transport URI endpoints in the usual manner.

• If the remote trading partner is also using WebLogic Integration, but is using a proxy server other than the WebLogic proxy server, then it is likely that the remote site is configured with the WebLogic proxy plug-in. When you are configuring a remote trading partner under these circumstances, you must specify the host and port of the trading partner's proxy server as the transport URI endpoints. The WebLogic proxy plug-in performs the necessary URL transformations to business messages received for that remote trading partner.

Using a Firewall

If your WebLogic Integration environment is configured with a firewall, make sure your firewall is configured properly so that business messages can flow freely to and from local trading partners via the HTTP or HTTPS protocols.

 

---

Setting Up a Secure Deployment

The following sections provide instructions for the tasks you must complete to set up a secure deployment:

• Step 1: Create the Domain

• Step 2: Configure WebLogic Server Security

• Step 3: Configure BPM Security

• Step 4: Configure B2B Integration Security

• Step 5: Configure Application Integration Security

Step 1: Create the Domain

We recommend that you use the BEA Configuration Wizard to create the WebLogic Integration domain for which you want to configure security. To create a WebLogic Integration domain, complete the following steps:

1. Start the Configuration Wizard, as described in Using the Configuration Wizard, available at the following URL:

   http://download.oracle.com/docs/cd/E13196_01/platform/docs70/confgwiz/index.html

2. Complete the configuration of the WebLogic Integration domain, which can be any of the following:

   • WebLogic Integration BPM domain

   • WebLogic Integration EAI domain

   • WebLogic Integration domain

Note: Make sure you use a WebLogic Integration template when creating the new domain; do not use a WebLogic Server or a WebLogic Portal template. By specifying a WebLogic Integration template, you can make sure that the domain created in this step is based on the WebLogic Server 6.x security realm in compatibility mode. The new WebLogic Server 7.0 realm, based on LDAP, is not supported with WebLogic Integration. If you create a new domain by selecting a WebLogic Server template, the new domain uses the new WebLogic Server 7.0 security realm, which is based on LDAP.

Step 2: Configure WebLogic Server Security

When configuring WebLogic Server security, be sure to do the following:

1. Obtain the server certificates for the local and remote trading partners. For SSL, server certificates are required for each instance of WebLogic Server involved in a trading partner request.

2. Consider the following questions:

   • Does the common name of the certificate match the host name of the machine on which the corresponding instance of WebLogic Server is running?

     If the two names are not the same, then the local WebLogic Server instance must be configured with hostname verification disabled. This requirements applies to the server certificate for any trading partner in any collaboration agreement configured locally. You can disable hostname verification in the WebLogic Server Administration Console by checking the Hostname Verification Ignored attribute on the SSL tab for the Server node.

   • Are the formats of the server certificate and private key for a remote trading partner supported by WebLogic Server?

     "About Digital Certificates" on page 4-7 lists the supported certificate formats. For server certificates, PEM encoded X.509 V1 or V3 is the most commonly accepted format by SSL servers.

     For private keys, PKCS8, which is the password-encrypted private key, is the most common format. Be sure to set the private key password so that WebLogic Server can read the private key.

   • What is the CA certificate chain for the WebLogic Server server certificate?

     A certificate chain is an array of digital certificates for trusted CAs, each of which is the issuer of the previous digital certificate.

     You may specify one file containing all the intermediate and root CA certificates. (Note that if the file contains more than one CA certificate, WebLogic Server requires a PEM encoded file.) If you use the root CA keystore to store trusted CA certificates, be sure to import the whole chain in to the root CA keystore.

3. Configure the WebLogic Keystore provider. WebLogic Server 7.0 supports keystore functionality. For complete details on creating keystores and configuring the WebLogic Keystore provider, see Configuring the Keystore in Implementing Security with B2B Integration.

   Note the following considerations for using keystores:

   • One caveat to using a keystore is that once you import a key and certificate with an alias into a keystore, overwriting that certificate file with a new certificate does not import of the new certificate into the keystore.

   • Make sure that your keystore is up-to-date with your current set of certificates and keys, and make sure that the WebLogic Integration repository reflects the relevant content of your keystore.

Step 3: Configure BPM Security

The security model provided by WebLogic Integration for business process management (BPM) functions comprises the following entities:

• Users and groups—A user is an individual who performs a certain task, such as programming or sales. A group is a collection of one or more users or groups that perform the same task. For example, Group A might represent a collection of users who are programmers; Group B, a collection of sales people.

  Within a security realm, the administrator (represented by the principal wlisystem) can specify the levels of access given to users and groups who want to use workflows and other resources. Users and groups are maintained in a WebLogic Server security realm. You can define groups and add users to those groups in the WebLogic Integration Studio. Each user you add is automatically and simultaneously added to the list of WebLogic Server users.

• Organizations—Entities that can represent different business organizations, geographical locations, or any other distinguishing items that are relevant to the particular business of an enterprise.

  Organizations are BPM-specific entities that exist outside the WebLogic Server security realm.

• Roles—Common areas of responsibility, ability, or authorization level that is shared by a group of individuals. A role may belong to one organization, but you can use the same name in multiple organizations.

  Roles map to WebLogic Server groups.

The task of configuring BPM security is basically one of defining users, groups, roles, organizations, and permission levels. Because you can define organizations and roles, you have a great deal of flexibility in organizing the users and groups that access BPM resources. The Studio provides tools that allow you to create and modify users, groups, roles, and organizations. The Studio also provides a method for managing permissions for users, groups, and roles in minute detail.

For more information about BPM security, see the following topics:

• "About Security Realms" in Administering Data in Using the WebLogic Integration Studio

• "Understanding the BPM Security Model" in Customizing WebLogic Integration in Starting, Stopping, and Customizing BEA WebLogic Integration. See especially the topic, "Configuring a Custom Security Realm."

• Configuring the Security Realms in Programming BPM Client Applications

Step 4: Configure B2B Integration Security

WebLogic Integration solutions that involve the exchange of messages between trading partners across firewalls have special security requirements, including trading partner authentication and authorization, as well as nonrepudiation.

To configure B2B security, you must perform the following tasks:

• Obtain the certificates and keys required for conducting B2B collaborations. Required certificates include those for the root CA, as well as the trading partner certificates and keys mentioned earlier, and the server certificate and key for each instance of WebLogic Server used in your environment.

• Create keystores for the certificate keys used in a WebLogic Integration environment, and register them with the WebLogic Keystore provider.

• Configure local trading partners.

• Configure remote trading partners.

• Implement nonrepudiation services, if desired.

• Implement the security requirements for the business protocols used.

The sections that follow provide recommendations and considerations for each of these tasks.

Obtaining Certificates

Before you begin configuring WebLogic Integration security, particularly if you plan to conduct B2B exchanges, make sure you have the following certificates and keys:

• Server certificates and keys for each instance of WebLogic Server used in the B2B exchanges. This requirement also applies to remote trading partners: for each remote trading partner you configure, you must have that trading partner's server certificate. These certificates are required by SSL.

• Root Certificate Authority for each certificate used in the environment.

  The root CA directory should contain only the root CA certificates for each trading partner's client, encryption, and signature certificate. The root CA directory must not contain the CA certificates for the server certificates. (The server certificates are configured in the domain's config.xml file.)

• Client certificates for each trading partner, whether local or remote. For local trading partners, you must also obtain the location of the client certificate's private key.

• Encryption and signature certificates for all trading partners. For local trading partners, you must also obtain the location of each certificate's private key.

Creating the Keystores

When you set up a WebLogic Integration domain for B2B collaborations, you must configure the WebLogic Keystore provider to create the following keystores:

• Private keystore

  Stores the local trading partners' private keys and certificates, such as the client, server, signature, and encryption certificates typically required for B2B collaborations. WebLogic Server retrieves a private key from this keystore to initialize SSL.

• Root CA keystore

  Stores the certificates of all the trusted certificate authorities (CAs). The WebLogic Keystore provider creates a trusted CA keystore that WebLogic Server uses, by default, to locate the trusted CAs used by SSL to verify client certificates.

You can use the JavaSoft JDK keytool utility or the WebLogic Server ImportPrivateKey utility to create each keystore and to add private keys to it. If neither keystore exists, it is created the first time you use either of these utilities to add a private key.

After you create the keystores and populate them with initial sets of keys, register them with the WebLogic Keystore provider, as described in "Step 2: Configure WebLogic Server Security" on page 4-11.

Configuring Local Trading Partners

Local trading partners send messages to remote trading partners using either HTTP or HTTPS. If you are using SSL in your B2B collaborations, which we strongly recommend, you need to configure the client certificate and key for each local trading partner.

Note the following about client certificates and keys for local trading partners:

• Both plain and password-protected keys are supported. The PEM, DER, PKCS8 formats are supported.

• PEM or DER encoded X509 V1 or V3 certificates are supported.

• The password for the private key is case-sensitive and is specified in the command line of the startWeblogic script in a Java system property.

Note the following about signature and encryption certificates and keys for local trading partners:

• Only password-protected private keys, using the PKCS8, format are supported.

• DER encoded certificates is recommended.

• You must copy the root CA certificate to the location pointed to by the CA certificate directory.

• The private key password is case-sensitive and is specified in the command line of the startWeblogic script in a Java system property.

Configuring Remote Trading Partners

If you are using SSL, as with local trading partners, you need to configure the client certificate and key for each remote trading partner.

Note the following about client certificates and keys for remote trading partners:

• The remote trading partner uses a client certificate to establish a two-way SSL connection with WebLogic Server in your domain. Make sure that this certificate matches the one specified for that trading partner in the WebLogic Integration repository.

• If the remote trading partner is also uses WebLogic Server, this information is stored in the repository as that trading partner's client certificate.

• If the remote trading partner is not based on WebLogic Integration, obtain a valid client certificate form that trading partner. (In the case of WebLogic Integration - Business Connect, you can use that software's administration tool to export a company's certificate to a file, and specify that file's location in WebLogic Integration.)

Note the following about signature and encryption certificates and keys for remote trading partners:

• Make sure you obtain both the signature and encryption certificates before configuring these certificates in the WebLogic Integration repository. Not all these certificates need to be same; however, one certificate may be used for both encryption and signatures.

• You must also obtain the CA certificates and add them to the root CA keystore (or directory if you are not using keystores). Self-signed certificates should also be added, if used.

Note the following about the remote trading partner's server certificate:

• You need to obtain the HTTP(S) server certificate of the remote trading partner's site. This is the server to which you establish the SSL connection.

• If the remote trading partner's site is also based on WebLogic Integration, and the remote site's Web server is WebLogic Server, use the certificate of that Web server as the trading partner's server certificate.

Implementing the Security Requirements for Business Protocols

Note that the business protocol with which a Collaboration Agreement is configured may have additional specific security requirements.

The following table lists additional sources of information about various business protocols.

Table 5-1 More Information About Business Protocols Used in B2B

For information about . . .	See this section . . .	In this document . . .
RosettaNet security	"Configuring RosettaNet Security" in Introduction	Implementing RosettaNet for B2B Integration
cXML security	"Security" in cXML Administration	Implementing cXML for B2B Integration
ebXML security	"Configuring Security" in Administering ebXML	Implementing ebXML for B2B Integration

 

Step 5: Configure Application Integration Security

WebLogic Integration provides the following security mechanisms for those parts of an integration solution that are created and maintained with application integration functionality:

• To connect to an Enterprise Information System (EIS), an application might need to provide certain credentials, such as a login name and password. For more information, see "Scenario 1: Connecting Using Specific Credentials" in Using Application Views by Writing Custom Code in Using Application Integration.

• When deploying an application view, you can configure security settings to grant or revoke read and write access to the application view by a WebLogic Server user or group. For more information, see "Deploying an Application View" in "Steps for Defining an Application View" in Defining an Application View in Using Application Integration.