Reverse proxy
Reverse proxy and Fortified ID products
Overview
Fortified ID does not have a reverse proxy product. We strongly recommend to use a reverse proxy infront of our products. The main reasons are:
1. Security A reverse proxy hides internal servers from the internet and can block malicious traffic before it reaches the backend.
2. Load balancing It distributes incoming requests across multiple backend servers to improve performance and reliability.
3. TLS termination The reverse proxy handles HTTPS encryption, so backend servers can communicate internally over simpler HTTP.
Example of reverse proxy rules
Depending on which reverse proxy product is used (see the section further down in this document), the interface for configuring the rules may differ slightly.
However, the information required to configure Fortified ID products generally follows the structure described below.
Communication
The end user browses to
https://dns_server_name/portal/(using HTTPS on port 443).
The reverse proxy (RP) forwards the request to
https://backend_server_name:8445/portalThe reverse proxy uses a certificate to establish the HTTPS connection between the end user and the reverse proxy.
The backend server (running the Fortified ID Portal) receives the request at
https://backend_server_name:8445/portalThe backend server uses its own certificate for the HTTPS connection between the reverse proxy and the backend server.
Default ports for Fortified ID products
The following default endpoints are used by Fortified ID components:
https://backend_server_name:8443/access
https://backend_server_name:8443/saml
https://backend_server_name:8443/oidc
https://backend_server_name:8445/portal
https://backend_server_name:8450/control
https://backend_server_name:8444/enrollment
https://backend_server_name:8446/pwdreset
https://backend_server_name:4443/mgmt
Which reverse proxy should I choose?
Overview
The recommended approach is to use an existing reverse proxy already deployed in the customer’s environment.
If the customer does not have an existing reverse proxy solution, you may need to install and configure one as part of the deployment.
An important consideration is the ongoing industry shift toward short-lived TLS certificates (47-day validity). This change will be introduced gradually and is expected to be fully adopted by 2029. The intent is that certificate issuance and renewal will be fully automated.
When selecting a reverse proxy solution, you should therefore ensure that automatic certificate management can be implemented together with the customer.
Best practice when choosing reverse proxy
Use an Existing Reverse Proxy
Whenever possible, use a reverse proxy that is already deployed and managed by the customer. Common examples include:
F5
Citrix NetScaler
SiteMinder
Azure Application Gateway
These solutions often already include certificate lifecycle management, which may simplify handling the upcoming 47-day certificate validity requirement.
If Running in a Windows Environment
Windows Server + IIS with Application Request Routing (ARR) can be used as a reverse proxy.
Many organizations already have processes or tooling for managing TLS certificates on Windows servers, which can also be leveraged for this setup.
Apache Web Server
Apache HTTP Server is another viable option.
Easy to install and configure
Well supported and widely used
However, you must ensure that automated certificate renewal is implemented to handle the shorter certificate validity periods.
A common approach is to use Let’s Encrypt: https://letsencrypt.org/sdc
Last updated