Deploying WebLogic Integration Solutions
|
 |
 |
|
|
 |
 |
The following sections describe how to set up and manage security for WebLogic Integration solution deployments:
Before you proceed with the remainder of this topic, be sure to read Introducing WebLogic Platform 8.1 Security in Introducing Security.
The foundation of every secure deployment of a WebLogic Integration solution is the set of security features provided by WebLogic Server. 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:
As the security administrator 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:
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.
When you create a WebLogic Integration domain using the Domain Configuration Wizard, the domain is configured to include:
For information about using the Configuration Wizard, see Creating WebLogic Configurations Using the Configuration Wizard.
All passwords are kept in encrypted form in the PasswordStore. WebLogic Integration does not require clear-text passwords. The PasswordStore the uses Sun JCE provider for password-based encryption. Access to passwords is controlled through an MBean API and passwords are accessed using password-aliases.
You use the WebLogic Integration Administration Console to manage passwords in the PasswordStore. For more information, see the following topics in Trading Partner Management in Managing WebLogic Integration Solutions:
WebLogic Integration requires that you use keystores to store all private keys and certificates. A keystore is a protected database that holds keys and certificates. If you have keys and certificates and use message encryption, digital signatures, or SSL, you must use a keystore for storing those keys and certificates and make the keystore available to applications that might need it for authentication or signing purposes.
When you set up a WebLogic Integration domain for trading partner integration collaborations, the following keystores are configured.
|
Stores private keys for local trading partners and certificates for both the local trading partner and remote trading partners. Certificates are of the following types: WebLogic Integration retrieves private keys and certificates from this keystore to use for SSL, message encryption, and digital signatures. For more information about certificates, see About Digital Certificates. |
|
|
WebLogic Server uses the trust keystore to locate trusted CAs for SSL. WebLogic Integration uses it to locate the trusted CAs while verifying signature and encryption. |
When you create a new domain using the WebLogic Platform Configuration Wizard and the WebLogic Integration template, the new domain contains Demo Keystores of type JKS. The Demo KeyStores performs the following actions:
You can use the Demo keystores in a development or testing environment, but you must either create or use existing identity and trust keystores suitable for production environment. To create a keystore and make it available for trading partner integration:
For information about refreshing the keystore using the WebLogic Integration Administration Console, see "Refreshing the Keystore" in Trading Partner Management in Managing WebLogic Integration Solutions.
In a clustered domain, you need to create and configure a separate keystore for each WebLogic Server.
WebLogic Integration supports role-based authorization. Although the specific users (principals) that require access to the components that make up your WebLogic Integration application may change depending on the deployment environment, the roles that require access are typically more stable. Authorization involves granting an entity permissions and rights to perform certain actions on a resource.
In role-based authorization, security policies define the roles that are authorized to access the resource. In addition to the built-in roles that are associated with certain administrative and monitoring privileges, security policies that control access to the following resources can be configured from the WebLogic Integration Administration Console:
Policies define the role required to invoke the process operations. For more information on the policies you can set, see "Process Security Policies" under "About Process Configuration" in Processes Configuration in Managing WebLogic Integration Solutions.
Policies define the roles required to subscribe and publish to a given channel. For more information, see "About Message Broker Channels" in Message Broker in Managing WebLogic Integration Solutions.
Policies define the roles required to execute services and subscribe for events on an application view. For more information, see "Managing Security" in Application Integration in Managing WebLogic Integration Solutions.
Once the roles required for access are set, the administrator can map users or groups to the roles as required.
Unlike membership in a group, which is directly assigned, membership in a security role is dynamically calculated based on the set of conditions that define the role statement. Each condition specifies user names, group names, or time of day. When a principal (user) is "in" a role based on the evaluation of the role statement, the access permissions of the role are conferred on the principal.
Before you configure the security for your WebLogic Integration domain, consider the following:
The following sections present a high-level discussion of these considerations and describe how they affect your WebLogic Integration security configuration.
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 inter-enterprise commerce, using Trading Partner Integration capabilities, you need to obtain and configure a specific set of digital certificates and keys. This set includes the following:
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:
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 "Transport-Level Security" in Trading Partner Integration Security in Introducing Trading Partner Integration.
The SSL protocol provides secure connections by supporting two functions:
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 Trading Partner Integration collaborations, you need to configure the following:
Not required by SSL, but strongly recommended, is the creation and use of identity and trust keystores for storing all the certificates and keys used in your WebLogic Integration domain. For more information about SSL, certificates, and keystores, see Configuring SSL in Managing WebLogic Security.
This section discusses the implications of using either an outbound proxy server or the WebLogic proxy plug-in.
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:
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 Trading Partner Integration to Use an Outbound HTTP Proxy Server" in Trading Partner Integration Security in Introducing Trading Partner Integration.
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:
The Web server then uses the WebLogic proxy plug-in, which you can configure to provide the following services:
To configure the WebLogic proxy plug-in, perform the following actions:
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.
The following sections provide instructions for the tasks you must complete to set up a secure deployment:
Create the WebLogic Integration domain using the Domain Configuration Wizard, as described in Configuring a Single-Server Deployment or Configuring a Clustered Deployment.
Note: We recommend that you configure your domain with SSL enabled.
The WebLogic Server Administration Console enables you to make additional customizations to your WebLogic Integration domain and default security realm. For information about customizing security features using the WebLogic Server Administration Console, see "Customizing the Default Security Configuration" in Managing WebLogic Security.
For a description of how to add firewall information to your domain configuration file, see Adding Proxy Server or Firewall Information to your Domain Configuration.
When configuring WebLogic Server security, be sure to do the following:
If the two names are not the same, then the local WebLogic Server instance must be configured with hostname verification disabled. This requirement applies to the server certificate for any trading partner in any Trading Partner Integration. 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.
Note: We do not recommend configurations that require you to disable hostname verification. Hostname verification prevents some types of security attacks.
About Digital Certificates 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.
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 trust keystore to store trusted CA certificates, be sure to import the whole chain in to the trust keystore.
Note: Note the following considerations for using keystores:
WebLogic Integration provides the following security mechanisms for those parts of an integration solution that are created and maintained with application integration functionality:
For more information, see "Scenario 1: Connecting Using Specific Credentials" in Using Application Views by Writing Custom Code in Using the Application Integration Design Console.
For more information, see "Steps for Defining an Application View" in Defining an Application View in Using the Application Integration Design Console.
Using WebLogic Workshop, a developer can edit Web application settings and Web service security-related deployment descriptors in the following three XML files before building and packaging the EAR file that contains your WebLogic Integration application:
A system administrator at deployment time may have more information regarding the production environment and security requirements. Under these circumstances, you can reconfigure the Web application settings and Web service security-related deployment descriptors in your EAR file as necessary by performing the following procedure.
Note: A developer typically adds any Service Broker control, Process control or callback selector annotations that are necessary for security to jcx or jpd files before packaging the EAR for deployment. However, these annotations can also be added or changed during this procedure.
web.xml and weblogic.xml, security-related deployment descriptors for Web applications that contain JPDs should be set to appropriate user credentials, method of authentication, and location of resources. wlw-config.xml, the web service exposure protocol should be set to HTTPS. For information about configuring security options in wlw-config.xml, see "wlw-config.xml Configuration Files" in the WebLogic Workshop Help.
Warning: Redeploying an application from WebLogic Workshop causes a loss of security authorizations. Deploy the EAR file using the WebLogic Server Administration Console to preserve your security authorizations.
For information about packaging and deploying EAR files, see "How Do I: Deploy WebLogic Workshop Web Services to a Production Server" in the WebLogic Workshop Help.
Once the WebLogic Integration application has been deployed on your production hardware, you can use the WebLogic Integration Administration Console to configure security policies and manage users.
For the procedure to start the WebLogic Server Administration Console see "Starting the Administration Console" in Introducing the WebLogic Integration Administration Console in Managing WebLogic Integration Solutions.
The following sections provide instructions for the tasks you must complete to configure security policies and manage users:
The Process Property Summary page lists every business process in the WebLogic Integration application.
From the Process Type Details page, you can configure the following security settings for the business process:
For descriptions of these settings and the procedures to configure them, see "Viewing and Changing Process Details" in Processes Configuration in Managing WebLogic Integration Solutions.
The View Dynamic Controls Summary page lists every dynamic control in the WebLogic Integration application.
On these pages, you can configure the client certificate or username/password settings used in outbound calls by the selected service broker or process control. For descriptions of these settings and the procedures to configure them, see "Adding or Changing Dynamic Control Selectors" in Processes Configuration in Managing WebLogic Integration Solutions.
On the Edit Channel Subscribe and Publish Policies page, you can configure the following security settings for the channel:
For descriptions of these settings and the procedures to configure them, see "Viewing and Changing Process Details" in Processes Configuration in Managing WebLogic Integration Solutions.
For the procedure to configure these security policies, see "Updating Security Policies" in Application Integration in Managing WebLogic Integration Solutions.
Enabling container-managed sign-on for an Application View allows Application Views to utilize any principal map that has been configured for the service connection. If container-managed sign-on is enabled for an Application View and the service connection it uses has been configured with a principal map, then at runtime the services invoked on the Application View will execute within the EIS instance with the identity of the EIS principal that maps to the WebLogic Server principal in effect when the service was invoked. If container-managed sign-on is disabled or no principal map exists on the service connection, then the authentication properties in the service connection itself (if any) are used to connect to the EIS instance
For the procedure to configure this setting, see "Enabling or Disabling Container-Managed Sign-On" in Application Integration in Managing WebLogic Integration Solutions.
The Adapter Instance Summary page lists the ID for each adapter instance in the WebLogic Integration application.
The Adapter Instance Service Connection page lists the name of each service connection for the adapter instance.
From the Adapter Instance Service Connection Details page, you can configure the following security settings:
For the procedure to configure these security policies, see "Updating Security Policies" in Application Integration in Managing WebLogic Integration Solutions.
For the procedure to configure this map, see "Viewing and Changing WebLogic Server to EIS Principal Mappings" in Application Integration in Managing WebLogic Integration Solutions.
The View and Edit Users page displays a list of all users within WebLogic Integration. From this page you can create new users, delete users, or access details—including group membership—for a selected user.
For information about managing users, see the following topics in User Management in Managing WebLogic Integration Solutions:
The View and Edit Groups page displays a list of all groups within WebLogic Integration. From this page you can create new groups, delete groups, or access details—including group membership—for a selected group.
For information about managing groups, see the following topics in User Management in Managing WebLogic Integration Solutions:
The View and Edit Roles page displays a list of all roles within WebLogic Integration. From this page you can create new roles, delete roles, or access details—including role conditions—for a selected role.
For information about managing roles, see the following topics in User Management in Managing WebLogic Integration Solutions:
WebLogic Integration domains includes the following default WebLogic Integration groups and roles that have access to worklist functionality:
The process of configuring worklist security is basically one of assigning users to groups, groups to roles, and ensuring that those roles have appropriate permission levels by defining policies. (For information on how to make these assignments, see Managing Production Users.) Once you have configured worklist security, you can manage owners for tasks in a worklist.
The WebLogic Integration Administration Console provides tools that allow you to manage users, groups, roles, and policies, along with worklist task ownership. For more information about configuring worklist security, see User Management and Worklist Administration in Managing WebLogic Integration Solutions.
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 Trading Partner Integration security, you must perform the following tasks:
For detailed information and procedures regarding configuration of Trading Partner Integration, see Trading Partner Integration Security in Introducing Trading Partner Integration.
|
|
|
in the module navigation bar to return to the home page.