Configure API Portal

This section describes how to configure the following on API Portal:

These configurations apply to both virtual appliance and software installations.

For details how to configure the look and feel of your API Portal end-user interface, see the API Portal Administrator Guide.

Configure the SSL certificate

To enable SSL on API Portal, you must configure Apache database to use the correct certificate.

For more details on API Portal certificate management, see the API Management Security Guide.

Configure Apache database in virtual appliance installation

API Gateway Appliance includes a self-signed certificate that enables HTTPS out-of-the-box. It is recommended that you replace it with a certificate tied to the host server and issued by the Certificate Authority (CA).

If you have API Portal running on API Gateway Appliance and you do not have an existing certificate, you can create or upload one using the Web Administration Interface of your virtual appliance. For more details, see Create an SSL certificate in the API Gateway Appliance Installation and Administration Guide.

  1. Import the SSL certificate, the root certificate, and any intermediate certificates to NSS database using the Certificate Database Tool (certutil):
  2. certutil -A -d <NSS database directory> -n <certificate nickname> -t CT,C,C -a -i <certificate file>

    For example:

    certutil -A -d /etc/apache2/mod_nss.d -n SSL-Cert -t ,, -a -i ssl.crt

    certutil -A -d /etc/apache2/mod_nss.d -n Root-Cert -t CT,C,C -a -i rootcert.crt

    certutil -A -d /etc/apache2/mod_nss.d -n Intermediate-Cert -t ,, -a -i intermediate.crt

    Note   You must import the root certificate with the C trust attribute set for SSL, otherwise the Apache service fails.

    For more details on certutil and the parameters, see NSS certutil documentation.

  3. To check that the certificates are successfully imported, list the certificates in the database:
  4. certutil -L -d <NSS database directory>

    An example output looks like this:

    Certificate Nickname       Trust Attributes
                                SSL,S/MIME,JAR/XPI
    ......
    <your CA cert nickname>     u,u,u
    Note   The trust attributes must be u,u,u. This shows that NSS has found a private key and linked it to the imported certificate.
  5. Open the /etc/apache2/vhosts.d/apiportal.conf file.
  6. Change the following line:
  7. NSSNickname Server-Cert
  8. to:

  9. NSSNickname <your CA certificate nickname>
  10. Restart Apache.

Configure the Apache database in software installation

  1. Open the /etc/httpd/conf.d/apiportal.conf file.
  2. Change SSLCertificateFile and SSLCertificateKeyFile to point to your CA certificate and key files.
  3. Restart Apache.

To protect your web server from a vulnerability giving remote attackers the ability to attain your internal IP address or internal network name, set ServerName to a proper FQDN.

Disable TLS 1.0 and TLS 1.1 on Apache

On an API Portal software installation, the Apache web server has TLS versions 1.0 and 1.1 enabled in addition to the TSL 1.2 that API Portal uses. Because TLS 1.0 and 1.1 have security vulnerabilities, it is recommended to disable them.

  1. To check which TLS versions are enabled, scan your API Portal port:
  2. sslscan <API Portal IP address>:<your https port>

    By default, API Portal uses port 443 for secure connections.

  3. To disable TLS 1.0. and 1.1, open the following file:
  4. /etc/httpd/conf.d/apiportal.conf
  5. Add the following SSL protocol definition for the secure connection:
  6. <VirtualHost *:443>
        SSLEngine on
        SSLCertificateFile "/etc/httpd/conf/server.crt"
        SSLCertificateKeyFile "/etc/httpd/conf/server.key"
    
        SSLProtocol TLSv1.2
    
        Header always append X-Frame-Options SAMEORIGIN
         ...
    </VirtualHost>
    
  7. Restart Apache.
  8. Run the sslscan again on your API Portal port to check that TLS 1.0 and 1.1 have been disabled.

Protect Joomla! from direct Internet access

To counter a session fixation vulnerability in Joomla!, it is recommended that you protect the Joomla! Administrator Interface (JAI) from direct Internet access.

  1. Open the following file:
    • Virtual appliance installation: /etc/apache2/conf.d/security.conf
    • Software installation: /etc/httpd/conf.d/security.conf
  2. Add an access restriction directive for the /administrator location. Specify the internal IP address range that is allowed to access JAI. For example:
  3. ServerTokens ProductOnly
    ServerSignature Off
      <Location /administrator>
        Order deny,allow
        deny from all
        allow from 10.232.14.
      </Location>
  4. To restart the web server configuration, enter the following:
  5. # /etc/init.d/apache2 reload

Limit the number of Joomla! failed login attempts

By default, Joomla! allows unlimited failed login attempts, which might pose a security risk. To protect Joomla! from brute force attacks, you can limit the number of failed login attempts that Joomla! allows:

  1. Log in to the JAI (https://<API Portal_host>/administrator).
  2. Click Extensions > Plugins.
  3. Locate and click the plugin LoginGuard Basic.
  4. Enter a value in seconds for how long the user account is locked.
  5. Enter a value for the number of failed login attempts before the account is locked.
  6. Ensure that you select Username in the Lock by field.
  7. Set the Status of the plugin to Enabled, and click Save & Close.

Joomla! is now protected. To protect API Portal from unlimited failed login attempts, you must also configure API Portal login protection.

Limit the number of API Portal failed login attempts

To protect API Portal from brute force attacks, you can limit the number of failed login attempts that API Portal allows:

  1. In the JAI, click Components > API Portal > Login Protection.
  2. Click Yes to enable login protection for API Portal.
  3. Enter a value for the number of failed login attempts before the user account is locked.
  4. Enter a value in seconds for how long the user account is locked.
  5. Click Save.

Add trusted OAuth hosts

To restrict API Portal users from accessing unauthorized OAuth endpoints, you can enter a list of permitted OAuth hosts in the OAuth whitelist:

  1. In the JAI, click Components > API Portal > Whitelisting.
  2. In the OAuth Whitelist field, enter the host names or IP addresses of the trusted OAuth hosts (separated by new lines). Do not enter API Manager hosts as these are added to the whitelist automatically.
  3. Click Save.

If you do not add your trusted OAuth hosts to this field, all requests to those hosts will be rejected by API Portal.

Add trusted API hosts

If you have APIs that are virtualized and published on a host other than an API Manager host, you can enter a list of permitted API hosts in the API whitelist:

  1. In the JAI, click Components > API Portal > Whitelisting.
  2. In the API Whitelist field, enter the host names or IP addresses of the trusted API hosts (separated by new lines). Do not enter API Manager hosts as these are added to the whitelist automatically.
  3. Click Save.

If you do not add your trusted API hosts to this field, all requests to those hosts will be rejected by API Portal.

Change the location of API Portal log files

By default, API Portal saves the Apache log files in the htdocs directory. For increased security, you can configure a different location to save the log files:

  1. In the JAI, click System > Global Configuration.
  2. On the System tab, enter the new location in the Path to Log Folder field. Apache must have permission to write to the new location.
  3. Click Save.

Configure Redis cache settings

If you are using Redis cache to cache APIs for API Portal, you can control how long data is preserved in the cache:

  1. In the JAI, click Components > API Portal > Cache Settings.
  2. In Cache Timeout, enter how long (in seconds) APIs are preserved in the cache.
  3. Click Save.

Use the Purge cache button to clear the cache at any time.

Configure terms and conditions text

To modify the API Portal Terms & Conditions content, edit the following file:

/opt/axway/apiportal/htdoc/components/com_apiportal/views/terms/tmpl/default.php

To customize the copyright notice that is displayed at the bottom of the API Portal pages, edit the following file:

/opt/axway/apiportal/htdoc/templates/purity_iii/tpls/blocks/footer.php

Reject requests containing unexpected or missing content type headers

It is best practice to reject requests containing unexpected or missing content type headers with the HTTP response status 406 Unacceptable or 415 Unsupported Media Type.

The Content-Type header specifies what media type is being sent with the request. If the Content-Type header is missing, empty, or unexpected the server must refuse to serve the request with an appropriate response, as allowing the request might lead to Cross-Site Request Forgery (CSRF) or even remote code execution (RCE).

Add the configuration in your .htaccess file, virtual host file, or global web server configuration. The following code snippet gives an example for a server processing only application/json and application/xml data.

# Check if the Content-Type header is missing or empty
RewriteCond %{HTTP:Content-Type} ^$
# AND the method type is POST, PUT or PATCH
RewriteCond %{REQUEST_METHOD} ^(POST|PUT|PATCH) [OR]
# OR Content-Type header is present
RewriteCond %{HTTP:Content-Type} !^$
# AND Content-Type value doesn't match one of the following, case-insensitive
RewriteCond %{HTTP:Content-Type} !^(application/json|application/xml) [NC]
# Then redirect with response 415 Unsupported Media Type and stop processing other conditions
RewriteRule ^ - [R=415,L]

Related Links