Port Assignments
Overview
DirX Access enables a fine-grained configuration of issued ports and the web applications publishing on them. This configuration emerged to face several problems:
-
Comparing to the older versions, the port assignment configuration enables a default state in which no unnecessary ports are opened. The DirX Access Manager Application is the only Web Application to be deployed automatically, and the administrator can subsequently choose the exact subset of web applications deployed for its project.
-
The environment in which DirX Access is deployed can present numerous constraints, effectively limiting the configuration possibilities. The port assignments enable to reflect these constraints and, e.g., deploy the internal web applications onto the intranet-facing ports and the external ones onto the extranet-facing ports. This is an improvement over the original state in which the web applications were always limited at the same port. This state was even strengthened by the introduction of the RESTful Web Services as a means of communication between DXA-internal clients and DirX Access Services container.
Management
The management of the Port Assignment configuration object is described in the Administrative Tasks chapter of this guide. In this section, we discuss into detail several connected topics.
Communication with DXA Clients (PEPs)
DirX Access provides unified interfaces for both internal and external clients. There is one specific configuration parameter that has to be set up to enable a port to be used by an internal client, and several additional strongly recommended ones.
The mandatory parameter is the „For DirX Access Client“ field. Enabling this field internally causes any request received at the port is granted the administrator-level permissions. This is necessary for the proper functioning of the internal DirX Access clients (PEPs), and, on the other hand, would represent a potential security threat for any other clients at this port.
|
From this reason, the strongly recommended configuration parameters are connected to the security. The administrator shall use the Crypto Container with the Keystore for a TLS-protected communication with the „Require SSL Client Authentication“ field set to Mandatory. |
This effectively means that, with proper handling of the key material, the TLS-level client authentication is used for the assignment of the administrator-level permissions. Any PEP deployment process then contains the key/certificate issuance belonging to the active System Keystore which is primarily oriented on protecting the DXA internal components communication.
Proxy Verification
The typical deployment contains some form of proxy, whether from the load-balancing reasons or as an additional security layer. In the case, several connection parameters are termined at the proxy (e.g., the TLS connection is not tunneled through the proxy), the DirX Access Services container has to get other means how to get to know these parameters (e.g., for the X.509 user authentication).
The configuration enables parameters for transferring this information in appropriate manner, however, this information shall be trusted. To provide the trust, the port assignment also enables to employ the TLS protection of the communication between the proxy and the DirX Access Services container, by enabling the „Verify proxy request resolution“ parameter and setting up the corresponding keystore/truststore parameters.
Assigning to a Server
Existing Port Assignments shall be assigned to the Servers. This relationship enables to define the published ports for each Server separately, hence, not only face different environment properties, but also set up the competencies of each Server differently, if necessary.
Assigning to a Web Application
The web applications published at given port, and in transition at given server, are determined via the list of the ports at each application. Web application can be assigned to any port and to any server. The „Deploy“ action subsequently deploys the application at all these ports.
Default Port Requirements
This section lists the default communication ports used by the DirX Access Services container. These ports are assumed to be open on your DirX Access hosts. When isolating DirX Access Services behind firewall or on secure subnet, ensure that communication between components on these ports is not interrupted.
The values listed are the system defaults. You can change these default values if necessary by:
-
Using the DirX Access Manager to change DirX Access Services ports.
| Port | Description | Directionality for SSL/TLS Authentication |
|---|---|---|
11111 |
Initial inter-component DirX Access communications (here: between DirX Access clients and Services container) |
n/a |
11112 |
Initial inter-component DirX Access communications over SSL/TLS (here: between DirX Access clients and Services container) |
Mutual |
11114 |
HTTP access (here: between Web browsers or Web services clients and DirX Access Services container) |
n/a |
11115 |
Secure HTTP access over SSL/TLS (here: between Web browsers or Web services clients and DirX Access Services container) |
Unilateral or mutual |
11118 |
Cache discovery (here: between DirX Access Servers running in one cluster group) |
Mutual - configurable |
11119 |
Cache communication (here: between DirX Access Servers running in one cluster group) |
Mutual - configurable |