Product Administration

WSO2 API Manager is shipped with default configurations that allow you to download, install and get started with your product instantly. However, when you go into production, it is recommended to change some of the default settings to ensure that you have a robust system that is suitable for your operational needs. Also, you may have specific use cases that require specific configurations to the server. If you are a product administrator, the follow content will provide an overview of the administration tasks that you need to perform when working with WSO2 API Manager (WSO2 API-M).

What is the WSO2 Administration Guide?

The WSO2 Administration Guide is a WSO2 guide that is common to all WSO2 products, and it explains all you need to know about how to set up and configure a WSO2 product to meet your enterprise requirements. In the subsequent sections we point you to the WSO2 Administration Guide where necessary.

[ 1 Upgrading from a previous release ] [ 2 Changing the default database ] [ 3 Configuring users, roles, and permissions ] [ 4 Configuring security ] [ 5 Configuring multitenancy ] [ 6 Configuring the registry ] [ 7 Performance tuning ] [ 8 Changing the default ports ] [ 9 Configuring custom proxy paths ] [ 10 Customizing error pages ] [ 11 Customizing the management console ] [ 12 Applying patches ] [ 13 Monitoring the server ]

Upgrading from a previous release

If you are upgrading from WSO2 API Manager 2.1.0 to WSO2 API Manager 2.2.0, see the upgrading instructions for WSO2 API Manager.

Changing the default database

By default, WSO2 products are shipped with an embedded H2 database, which is used for storing user management and registry data. We recommend that you use an industry-standard RDBMS such as Oracle, PostgreSQL, MySQL, MS SQL, etc. when you set up your production environment. You can change the default database configuration by simply setting up a new physical database and updating the configurations in the product server to connect to that database.

For instructions on setting up and configuring databases, see the following sections in the WSO2 Administration Guide.

Setting up the Physical Database

You can use the scripts provided with WSO2 API-M to install and configure several other types of relational databases. For more information, see the following sections.

Setting up Embedded H2	Setting up Remote H2
Setting up IBM DB2	Setting up IBM Informix
Setting up MySQL	Setting up Microsoft SQL
Setting up Oracle	Setting up Oracle RAC
Setting up PostgreSQL	Setting up a MySQL Cluster
Setting up Embedded Derby	Setting up Remote Derby
Setting up MariaDB

Changing the Carbon Database

WSO2 API-M is shipped with an H2 database, which serves as the default Carbon database. You can change this default database to one of the standard databases listed below.

When changing the default database, which is H2, to any other RDBMS, be sure to change all the other required datasources (WSO2AM_DB, WSO2AM_STATS_DB, WSO2_MB_STORE_DB, WSO2_METRICS_DB, etc.) to the same RDBMS. For more information, see Changing the Default API-M Databases.

Configuring users, roles, and permissions

The user management feature in your product allows you to create new users and define the permissions granted to each user. You can also configure the user stores that are used for storing data related to user management.

For more information on working with user management, see the following sections in the WSO2 Administration Guide.
For WSO2 API Manager specific user management related information, see the following sections in the WSO2 API Manager Guide.

Configuring security

After you install WSO2 API Manager, it is recommended to change the default security settings according to the requirements of your production environment. As API Manager is built on top of the WSO2 Carbon Kernel (version 4.4.11), the main security configurations applicable to API Manager are inherited from the Carbon kernel.

For instructions on configuring security in your server, see the following topics in the WSO2 Administration Guide.

Important!

If you are configuring your production environment, be sure to check the Security Guidelines for Production Deployment before applying any security configurations.

Securing Passwords in Configuration Files	All WSO2 Carbon products 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 Carbon products. The following topics will be covered under this section: Encrypting Passwords with Cipher Tool Encrypting passwords using the automated process Encrypting passwords manually Changing encrypted passwords Resolving Encrypted Passwords Enter password in command-line Start server as a background job Carbon Secure Vault Implementation Customizing the Secure Vault configuration Creating a Secret Callback Handler Creating a custom Secret Repository
Configuring Transport-Level Security	The transport level security protocol of the Tomcat server is configured in the `<PRODUCT_HOME>/core/conf/tomcat/catalina-server.xml` file. Note that the ss`Lprotocol` attribute is set to "TLS" by default. The following topics will guide you through the configuration options: Enabling TLS and disabling SSL support Disabling SSL support for products with JDK 1.8 Enabling TLSv1.1/TLSv1.2 for products with JDK 1.7 Disabling weak ciphers Disabling weak ciphers for the Tomcat transport Disables weak ciphers for the PassThrough transport Changing the server name in HTTP response headers
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 `<PRODUCT_HOME>/core/repository/conf/sec.policy` file. You modify this file to change the Java security permissions as required.
Using Asymmetric Encryption	WSO2 products 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. The following topics explain more details on keystores. Understanding keystores Setting up keystores for WSO2 products Default keystore settings in WSO2 products Managing keystores
Using Symmetric Encryption	WSO2 Carbon-based products use asymmetric encryption by default as explained in the previous section. From Carbon 4.4.3 onwards, you have the option of switching to symmetric encryption in your WSO2 product. Using symmetric encryption means that a single key will be shared for encryption and decryption of information.
Mitigating Cross Site Request Forgery Attacks	Cross Site Request Forgery (CSRF) attacks trick you to send a malicious request, by forcing you to execute unwanted actions on an already authenticated web browser. For more information, see the following sections that describe the impact of the Cross Site Request Forgery (CSRF) attack and how to mitigate it. How can CSRF attacks be harmful? Mitigating CSRF attacks Securing web applications Securing Jaggery applications
Mitigating Cross Site Scripting Attacks	Cross Site Scripting (XSS) attacks use web applications to inject malicious scripts or a malicious payload, generally in the form of a client side script, into trusted legitimate web applications. For more information, see the following sections that describe the impact of XSS attack and the approaches you can use to mitigate it. How can XSS attacks be harmful? Mitigating XSS attacks
Enabling HostName Verification	Hostname verification is enabled in WSO2 products 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 TLS Termination	When you have Carbon servers fronted by a load balancer, you have the option of terminating SSL for HTTPS requests. This means that the load balancer will be decrypting incoming HTTPS messages and forwarding them to the Carbon servers as HTTP. This is useful when you want to reduce the load on your Carbon servers due to encryption. To achieve this, the load balancer should be configured with TLS termination and the Tomcat RemoteIpValve should be enabled for Carbon servers.