Page Comparison

...

• In Tomcat's server.xml only configure an AJP Connector on the loopback interface and disable all other Connectors:

  No Format
  <Connector port="8009" address="127.0.0.1" enableLookups="false" redirectPort="443" protocol="AJP/1.3" maxPostSize="100000" />

• In Apache httpd with mod_ssl configure a VirtualHost with TLS (not covered here) and proxy requests to the idp context to the servlet container (adjust to taste if your IDP runs in a different context):

  No Format
  <Proxy ajp://127.0.0.1:8009/idp/*> Require all granted </Proxy> ProxyPass /idp/ ajp://127.0.0.1:8009/idp/

• If you offer support for a backchannel repeat the same on the backchannel 8443 vhost (, using the IDP's backchannel key pair, not the webserver's SSL one), also making sure httpd does not get in the way with evaluation of client certificates by the IDP application (SSLVerifyClient optional_no_ca):

  No Format
  <Location /idp> Require all granted SSLOptions +StdEnvVars +ExportCertData SSLVerifyClient optional_no_ca SSLVerifyDepth 10 </Location> <Proxy ajp://localhost:8009/idp/*> Require all granted </Proxy> ProxyPass /idp/ ajp://localhost:8009/idp/

...

One example for this would be use of plain HTTP between the servlet container and the web server (e.g. Nginx, Lighttpd, Pound, etc.). TLS is offloaded to/terminated at the web server. The web server listens on port 443 and proxies all requests to the container, which is listening on port e.g. 8000 with a plain HTTP connector. The container must not be directly accessible from the outside world (e.g. by only listening on the loopback interface).
For backchannel support httpd may also listen on port 8443, proxying requests to the same container port (e.g. 8000) – but possibly a different port on the container might be needed (e.g. 8080) to tell the ports appart in the IDP application. EIther Either way, the keypair must differ for the backchannel port (i.e., the IDP's backchannel credentials. , not web server TLS keys), as usual.

The container may need additional configuration to correctly virtualise virtualize the scheme (https vs. http), port (443 vs. 8000) and possibly host name. E.g. for Apache Tomcat those are the scheme, proxyPort and proxyName attributes on the Connector, respectively.

...

• Since the load balancer will likely be on a different host/machine/system pay attention to properly virtualize the scheme, port and hostname in the container.
• For backchannel support it may be easier (or necessary) to configure TLS ( with the IDP's backchannel credentials) key pair on the container itself (e.g. with a HTTPS Connector on port 8443) and pass through port 8443 from the load balancer unmolested.
• Depending on the technologies involved (HTTP proxying, SNAT, etc.) the container may need additional configuration to get the correct information about the HTTP User Agent's IP address from the loadbalancer.

Systemd-socket-proxyd

...

• This does not make use of TLS offloading, so the container will perform TLS itself (e.g. on port 9443 for web browser/front channel requests), though listening it will listen only on the loopback interface (Tomcat: address="127.0.0.1")
• The container needs to be properly virtualized, with the externally visible (logical) scheme and port. For Tomcat e.g. scheme="https" proxyPort="443" on a Connector port="9443".
• For backchannel requests you'd forgo use of the systemd proxy and directly expose another HTTPS connector on the container, e.g. on port 8443, listening on all interfaces (or a specific external one), with the IDP's backchannel key pair, of course.
• All proxy startup and tear down happens dynamically in the container's systemd unit file, so no additional processes need to be managed and monitored.
• But those external server/proxy processes still need to exist and bits will still need to be passed between 2 servers, which may incur some of the general proxying problemsissues.

Examples TBD.