This is the latest release in the 6.x.x family. For EI 7.0.0, click here.

All docs This doc
Skip to end of metadata
Go to start of metadata

WSO2 Enterprise Integrator 6.6.0 (WSO2 EI) consists of three profiles: ESB profile, Business Process profile, and the Message Broker profile. See the introduction for more information. These profiles are separate runtimes that need to be configured and managed separately. If you are a product administrator, the following topics will provide an overview of the various administration tasks that are common to all profiles of WSO2 EI. Follow the links provided under each section for detailed instructions on each topic. 

Upgrading from a previous release

WSO2 Enterprise Integrator 6.6.0 is a comprehensive integration solution that includes the functionality that was previously encapsulated in WSO2 ESB, WSO2 DSS, WSO2 MB, and WSO2 BPS. Therefore, you can upgrade to WSO2 EI 6.6.0 from each of those products.


When you cluster WSO2 EI, the three separate profiles (runtimes) included in WSO2 EI should be separately clustered according to your requirement. See the following topics for instructions on clustering each profile in WSO2 EI:

Production deployment guidelines

Follow the production deployment guide in the administration guide:

Changing the default databases

Each of the profiles in WSO2 EI contains an embedded H2 database (Carbon database), which is used for storing user management and registry data for that profile. Note that the Message Broker profile in WSO2 EI contains a default broker-specific database in addition to the Carbon database.

You can change the default database configurations in each of the EI profiles by setting up new physical databases, and updating the relevant configurations in each profile. We recommend the use of an industry-standard RDBMS such as Oracle, PostgreSQL, MySQL, MS SQL, etc. when you set up your production environment.

Configuring users, roles, and permissions

See the following topics for instructions on configuring users, roles, and defining permissions for each user.

Configuring the System AdministratorThe admin user is the super tenant that will be able to manage all other users, roles and permissions in the system by using the management console of the product. Therefore, the user that should have admin permissions is required to be stored in the primary user store when you start the system for the first time. The documentation on setting up primary user stores will explain how to configure the administrator while configuring the user store. The information under this topic will explain the main configurations that are relevant to setting up the system administrator.
Configuring the Authorization ManagerAccording to the default configuration in WSO2 products, the users, roles and permissions are stored in the same repository (i.e., the default, embedded H2 database). However, you can change this configuration in such a way that the users and roles are stored in one repository (user store) and the permissions are stored in a separate repository. A user store can be a typical RDBMS, an LDAP or an external Active Directory. 

The repository that stores permissions should always be an RDBMS. The Authorization Manager configuration in the user-mgt.xml file connects the system to this RDBMS. The information under this topic will instruct you through setting up and configuring the Authorization Manager.  

Configuring User Stores

The user management feature allows you to maintain multiple user stores for storing users and their roles. See the following topics for instructions:

Managing Users, Roles, and PermissionsCreate new users, roles and assign permissions using the management console.

Configuring security

It is recommended to change the default security settings in each profile of WSO2 EI according to the requirements of your production environment.  As all profiles in WSO2 EI are WSO2 servers built on top of the WSO2 Carbon Kernel, the main security configurations are inherited from the Carbon kernel.  For instructions on configuring these main security settings, see the following topics:

Configuring Transport-Level Security

The transport level security protocol of the Tomcat server is configured in the catalina-server.xml file. Note that the ssLprotocol attribute is set to "TLS" by default. 

Using Asymmetric Encryption

WSO2 servers use asymmetric encryption by default for the purposes of authentication and data encryption. In asymmetric encryption, keystores (with key pairs and certificates) are created and stored for the product. It is possible to have multiple keystores so that the keys used for different use cases are kept unique.

Using Symmetric Encryption

You also have the option of switching to symmetric encryption for the EI profile. Using symmetric encryption means that a single key will be shared for encryption and decryption of information. 

Enabling Java Security Manager

The Java Security Manager is used to define various security policies that prevent untrusted code from manipulating your system.  Enabling the Java Security Manager for WSO2 products activates the Java permissions that are in the sec.policy file. You modify this file to change the Java security permissions as required.

Securing Passwords in Configuration Files

All WSO2 servers contain some configuration files with sensitive information such as passwords. Let's take a look at how such plain text passwords in configuration files can be secured using the Secure Vault implementation that is built into each server.

The following topics will be covered under this section:

When you use the ESB profile of WSO2 EI, it is also possible to encrypt passwords and other sensitive information in synapse configurations. See Working with Passwords in the ESB Profile for instructions.

Resolving Hostname Verification

Hostname verification is enabled in WSO2 servers by default, which means that when a hostname is being accessed by a particular client, it will be verified against the hostname specified in the product's SSL certificate.

Configuring custom headers to responses in tomcat server

This is available only as an update(WUM or Updates 2.0) and is effective from 17th September 2021 (2021-09-17). For more information on updating WSO2 Enterprise Integrator, see Updating WSO2 Products or go to WSO2 Updates 2.0.

Navigate to the <EI_HOME>/conf/tomcat/web.xml file and add the sample code given below, according to your header requirement. The sample given below shows how to add the Referrer-Policy header.



 To add multiple headers to the same filter-mapping, use following sample in the <init param> section as comma separated key value pairs.



Logs in WSO2 EI 6.6.0See the complete list of logs that are available for the profiles of WSO2 EI.
Configuring Log4j2 Properties

WSO2 EI 6.6.0 version introduces a new log4j implementation (log4j2). See the instructions on configuring log4j2 for EI 6.6.0.

Managing the growth of Log4j logsThe growth of Carbon logs and audit logs in your EI profiles can be controlled.

Monitoring HTTP Access Logs

HTTP Requests/Responses are logged in the access log(s) and are helpful to monitor your application's usage activities, such as the persons who access it, how many hits it receives, what the errors are etc.

Applying patches 

For information on updating WSO2 EI with the latest available patches (issued by WSO2) using the WSO2 Update Manager (WUM), see the documentation on WSO2 Updates.

Working with profile-specific administration tasks

See the following topics for information on administration tasks that are specific to WSO2 EI:

  • No labels