Firewalls

Firewalls are an integral part of securing any network, especially those connected to external networks. A firewall can be deployed in multiple places within a Windchill system. The most common location for a firewall is between the client tier and the web server tier.

Most client applications access Windchill using HTTP or HTTPS connections, so an HTTP or HTTPS connection must be available. The default ports are 80 and 443 for HTTP and HTTPS, respectively.

Some Java clients may access Windchill directly using Java’s Remote Method Invocation (RMI). These clients can attempt direct connection to the server by default, using the RMI ports specified in the following wt.properties:

RMI is a Java-centric remote procedure called (RPC) mechanism that is implemented on sockets. RMI stub objects perform a remote method invocation between an RMI client and an RMI server. These stub objects contain a host name and port number. The client uses these stub objects when opening TCP and IP connections. Windchill exposes only two RMI objects to clients: a server manager object and a method server object. Other RMI objects are used server-to-server to coordinate cached information, but these RMI objects are not necessary for clients to connect.

RMI communication can also be forced to “tunnel” over HTTP or HTTPS. Tunneling over HTTP is no more secure than direct RMI communication. However, tunneling can leverage a reverse proxy by encrypting HTTP and HTTPS traffic. For more information on tunneling RMI, see Windchill Runtime Environment.

Controlled by the java.rmi.server.hostname property, the Windchill server host is used in URLs and RMI stubs and must resolve to an IP address for clients inside and outside the firewall. If the firewall is performing network address translation or is configured to proxy Windchill connections, the host names presented by Windchill to its clients must be valid to connect to the servers.

Many existing Windchill applets and applications use Java RMI to invoke server transactions. There is a continuing shift of focus from this form of communication towards HTTP and XML. But for now, the Windchill development environment continues to support code generation of classes that use RMI to invoke remote service methods.

It is increasingly common for systems to be configured with a web server tier separated from the Windchill application server. The servlet engine is still configured to run on the same server as Windchill. The Windchill installation files include the Apache-based web server named PTC HTTP Server and the Embedded Servlet Engine (which is based on Apache Tomcat). For details on configuring Windchill to work with a remote Apache web server, see Configuring Apache and Tomcat With Other Options.

In some situations, it may be ideal to configure a firewall between the web server tier and the Windchill application server. If this is the case, the web server must be capable of communicating with the following components:

In the default PTC HTTP Server and Embedded Servlet Engine configuration, these ports are used by the ajp13 protocol. There is a single port per Windchill method server running plus a range of ports. The port range allows for handling additional method servers as they are configured and is calculated based on the following logic:

◦ The minimum number of ports available is 9 (which is the difference of wt.method.maxPort and wt.method.minPort properties) + 1 for an additional spare method server.

The port range is used to allocate AJP workers in the <httpserver_home>/conf/extra/workers.properties file. PTC HTTP Server communicates with Embedded Servlet Engine through these ports.

Another common location for a firewall is between the database server and the application server. For more information about the appropriate ports and protocols that must be allowed, see the documentation for the database software.