Skip to content

For extra security and vulnerability reasons, the Apache Tomcat bundled within MetaKarta can be updated as follows:

Tomcat Upgrade To The Current Patches

Any new version of MetaKarta includes the latest version of Tomcat for bug fixes, performance, security and vulnerability reasons. According to the tomcat 9 changelog https://tomcat.apache.org/tomcat-9.0-doc/changelog.html, the last Common Vulnerabilities and Exposures (CVE) fix was made in 9.0.30. Therefore, there is no real benefit to upgrade to the latest version. In addition, it is not recommended that you manually install / patch the version of Tomcat bundled in MetaKarta as new Tomcat versions may not be compatible and require more files to be copies. The following process describe the patch process anyway although not officially supported:

  1. Check the version of Apache Tomcat that was bundled within your MetaKarta (e.g. Tomcat 9.0.45) which is expressed in: $MM_HOME/Documentation/License/MIMM-ThirdParty-LICENSES.html and $MM_HOME/tomcat/RELEASE-NOTES

  2. Download the latest patch version (e.g. 9.0.46) within the same major version:  https://tomcat.apache.org/download-90.cgi

  3. Unzip in temporary directory

  4. Stop Tomcat

  5. Copy the lib directory from that temporary directory to the $MM_HOME/tomcat/lib (overwriting files if necessary)

  6. Restart Tomcat

Tomcat Check For Allowed Referrer

For additional protection, we recommend enabling Tomcat to check for allowed referrer:

  1. Edit $MM_HOME/tomcat/conf/web.xml

    • Uncomment the two filter sections in the 'Checks referrer is allowed' section. The variable ${server.fqdn} will be substituted with the value of M_SERVER_FQDN in tomcat.properties

  2. Edit $MM_HOME/tomcat/conf/tomcat.properties by:

    • Changing the M_SERVER_FQDN variable from localhost to &ltmyMMServer.myDomain>

Tomcat Configuration to avoid TLS violation of Cryptographic Standard STD-IT-0005

MetaKarta uses Java 17 that supports Transport Layer Security (TLS) 1.3, but it is compiled for Java 8 that supports TLS 1.2. To ensure that Tomcat does not "drop down to using" a lower version (1.1. and 1.0), one must configure Tomcat appropriately.

For more details on configuring Tomcat SSL, see Tomcat's documentation at: https://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support

Tomcat Configuration to include HTTP security headers

For additional protection, you can edit $MM_HOME/tomcat/conf/web.xml

By default, the application sets the following to the recommended values: * Content-Security-Policy * X-Content-Type-Options * X-XSS-Protection

The X-Frame-Options is not set by default, it can be done manually by adding the following fragment: 

<init-param>
    <param-name>X-Frame-Options</param-name>
    <param-value>sameorigin</param-value>
</init-param>

The HSTS headers are not necessary as when the application is configured for HTTPS then HTTP is not allowed at all, and do not provide automatic redirection. However, you may want/need to add it, you can do so manually by adding the following fragment: ** 

<init-param>
    <param-name>Strict-Transport-Security</param-name>
    <param-value>max-age=31536000; includeSubDomains</param-value>
</init-param>

Tomcat Configuration for Access Control with Valve

The first line of defense of the Tomcat based primary MetaKarta server or any of its metadata harvesting agents / MIMB servers requires a proper firewall setup. As a last line of defense, the tomcat remote address valve can be configured for access control.

In such case the Tomcat of any metadata harvesting agents / MIMB server should configure with a valve to only accepts requests from its associated primary MM server. This requires to edit the file tomcat/conf/MetaKarta/localhost/MIMBWebServices.xml in order to add the following line: <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127.\d+.\d+.\d+|::1|0:0:0:0:0:0:0:1">

For more details on configuring Tomcat access control with valve, see Tomcat's documentation at: https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Remote_Address_Valve

Secret / Password Encryption

There are a few cases where any account secret / user password is stored in the repository database using an encryption method that is two-way in order to restore the original password just before calling a third-party API later:

  1. When configuring metadata harvesting (Model > Import > Setup), some bridge parameters require authentication to the source technology / server (e.g. user / password of a database or a BI server)

  2. When configuring LDAP based authentication (MANAGE > Users > LDAP)

  3. When configuring Email notification (MANAGE > Email Notification)

  4. When configuring Cloud Identity (MANAGE > Cloud Identity)

Because of this requirement, MetaKarta cannot use key-based industry standard encryption. It instead stores such user/password in the repository database (i.e. at rest) using a confidential proprietary reversible encryption algorithm based upon industry standards.

NOTE 1: A second level of encryption can also be used during transport (i.e in motion) using 6.5 Custom integration for Secure Socket Layer (SSL) communication

  1. HTTPS for remote metadata harvesting from the main MetaKarta Server and a remote Harvesting Agent / Server. See Configuring SSL to access Remote Servers

  2. LDAPS for authentication to the Enterprise Directory.

  3. When using LDAP based authentication. See Configuring the MM Application Server to securely connect via LDAPS to the Enterprise Directory

NOTE 2: Alternative secret / password encryption and external storage solutions are available using Cloud Identity and Cloud Secret Vaults (such as Amazon Web Services, Microsoft Azure, or Google Cloud). See, MANAGE > Cloud Identity

Outside Access to MMDoc and MIMBWebServices

By default, MMDoc and MIMBWebServices will only be accessible from localhost (the machine on which they are installed). If the user wants to access them from another machine, they will have to configure them to allow such access. For MIMBWebServices, this will be important for Remote MIMB Server only and not for the local one and not for Agents.

To configure the web application, the Setup utility has been enhanced with a new command line option:

'setup -wa [MMDoc|MIMBWebServices]=[ALL|LOCALHOST|List of Ips or Hosts]'

The webapp name should be MMDoc or MIMBWebServices and the possible values to allow access from are:

  • ALL: which allows everybody to connect (not recommended but useful for troubleshooting)

  • LOCALHOST: which allows to reset to the default of localhost only

The allowed value is a comma separated list of:

  • IPv4 addresses

  • IPv6 addresses

  • Host Name which will be resolved to an IP address

When specifying a list of values, the localhost is always appended as it is necessary for local communication.