Web Services

ActivID CMS is a Java-based Web application that leverages the Microsoft IIS server as an HTTPS engine for communicating with the Web browsers that the operators and users are using to access the ActivID CMS portals. The HTTPS engine also provides a Web services interface for some of the ActivID CMS APIs. The actual execution and runtime for the ActivID CMS Java files is based on WildFly, which is automatically installed with ActivID CMS.

ActivID CMS security relies heavily on a secure Web services environment. Therefore, it is crucial that you follow the Microsoft recommendations regarding Web server security hardening. It is strongly recommended that you read and review the documentation found at the following links for further information on how to secure your Microsoft IIS Web server.

Securing the Windows Server

Use the following URL for details about securing a Windows server:

In addition, it is recommended that you install and run security analyzer tools, for instance:

Based upon the Microsoft generic hardening recommendations, it is recommended that you apply your own internal hardening process. However, the hardening process is outside the scope of this documentation.

To ensure that your ActivID CMS systems work properly in a newly-configured environment, it is imperative that you implement and use a comprehensive change control process. The purpose of this process is to fully test each new configuration or environment change in a dedicated test network before applying the change across your deployed ActivID CMS production systems.

Observing ActivID CMS-Related Security Considerations

This section assumes that you have implemented the recommendations in the previous section regarding securing your IIS Web server. To securely implement ActivID CMS within your IIS environment, apply the following guidelines:

  • Make sure that the ActivID CMS Web site runs only on the ActivID CMS server. Remove all other Web sites (for example, the default Web Site and other services that might be enabled as part of the IIS service).

  • Configure the IP address and Host header values for the ActivID CMS Web site.

  • During ActivID CMS installation, change the default TCP port to 80 (for HTTP traffic) and the SSL TCP port to 443 (for HTTPS traffic).

  • Using the Performance tab, configure the IIS maximum number of connections to match your requirements (in general, 150 concurrent sessions is typically sufficient).

  • Configure the IIS default setting to match your longest page return time (this assumes that your ActivID CMS deployment is fast enough to return any query faster than 120 seconds).

  • Configure your IIS server to use certificates issued from your own CA The Certificate Authority (CA) issues and manages security credentials and public keys for message encryption in a networks environment. rather than the self-generated certificates deployed during ActivID CMS installation. If you use ActivID CMS in peered mode, use different certificates for each server. Make sure that any soft certificates issued during the build process of ActivID CMS are revoked and the CRL is updated.

  • Change IIS application protection to High for the ActivID CMS Web site, Operator Portal, and User Portal Web instances.

  • Make sure that the ActivID CMS Web site, Operator Portal, and User Portal Web instances are configured with only Log Visits and Read Access. These Web sites must have Execute permissions for scripts and executions.

  • Improve audit traceability by assigning different domain users to run the Operator Portal and User Portal. Make sure that both domain users are members of the local user group that was suggested in Observing ActivID Credential Management System-Related Security Considerations.

  • Make sure that the users that run the Operator Portal and User Portal Web instances are not local administrators on the ActivID CMS system(s), or administrators in the domain.

  • Disable Web access to the ActivID CMS Web site root.

  • Configure the WildFly memory assignment to match your server specifications.

Apache AJP13 Configuration

By default, CMS is installed with both IIS as Web front-end and a Java Web server as back-end (aka the CMS Server), on the same machine. These two components communicate with each other using the Apache AJP13 protocol.

The following figure illustrates the connection between the CMS front-end (IIS) and the CMS back-end (the CMS Server) on two machines, using a hardened AJP13 tunnel.

Apache AJP13 Configuration

To harden the security of the Apache AJP13 link, use one or more of the following methods:

  1. Put the CMS Server service behind the DMZ.

  2. Define a specific firewall rule that only permits access of the AJP13 port from an IIS server front-end.

  3. Configure the shared secret on both sides of the connector. The AJP13 protocol supports a simple shared secret-based authentication mechanism: both the AJP connector and the AJP13 worker can define a shared secret in their configuration files.

    The Apache AJP13 connector only accepts requests from users that send the correct secret in the command. The secret is stored in clear (unencrypted) text in the workers.properties (entry secret) and standalone.xml (entry secret-checker) files . The secret is sent over between the client and server in clear text.

  4. Configure the CMS Server standalone.xml file with a request filter that only accepts requests from the IIS server front-end.

  5. Disable any other unused connectors in the CMS Server container standalone.xml file (specifically, the HTTP connector to avoid having CMS listen on ports other than AJP13 from allowed systems).

  6. Depending on the security policy of the deployment, the TCP traffic might be further encrypted between the front-end and the CMS server using IPsec or SSH tunneling.

Note: The standalone.xml file is in the cms_install_dir\wildfly\standalone\configuration directory.