Web server with local orchestrator

Web server with local orchestrator

For scenarios where using the Orchestrator as a network gateway proxy is not viable because the network is untrusted (e.g. zero trust architectures), the Orchestrator can be deployed on the same host as the application web server.

This is similar to the sidecar model used in container service mesh architectures to restrict access between microservices. Access to the application or service is only allowed through the proxy that runs adjacent to the web server.

RP (Client) Orchestrator Configuration

Orchestrators deployed on the same host as the web server will often be configured as an RP Orchestrator (OIDC client), using a central IdP Orchestrator to provide authentication and policy. See the RP-IDP Orchestrator documentation for details.

Configuring the Web Server

Configure the web server to run on a local interface (e.g. localhost or using a port that does not conflict with the Orchestrator (e.g. 8080). The Orchestrator will run on a public interface of the host, handling TLS termination and all requests other than those originating on the host itself.

In the following examples, web servers are configured to:

  • listen for connections on localhost, port 8080 (only)
  • respond to requests for the server name “app.myhostname.local”
  • deny access from everywhere except localhost

NGINX serving on localhost only

server {
    server_name app.myhostname.local;
    location / {
        root /www/app;
        deny all;

Apache serving on localhost only

Listen http

ServerName app.myhostname.local
DocumentRoot "/www/app"
Deny from all
Allow from

The hostname app.myhostname.local should be configured in /etc/hosts to resolve to

App Gateway for a local server

If the adjacent Orchestrator were configured as a stand-alone proxy, the corresponding appgateways configuration might look like:

  - name: App
    basePath: /
    host: app.myhostname.com
    upstream: http://app.myhostname.local:8080
    errorPage: https://app.myhostname.com/error

If the adjacent Orchestrator was configured as an RP Orchestrator, the corresponding fabric configuration might look like:

    - upstream: 
      host: app.myhostname.com # Optional
      authEndpoint: https://idp.internal.net:8443/auth
      clientID: idp-orchestrator
      clientSecret: <oidc-secret-in-vault> 
      providerIssuer: https://idp.internal.net
      redirectURL: https://app.myhostname.com/oidc
        - location: /
          appgatewayName: my-app1
        - location: /downloads
          appgatewayName: downloads-app1
        - /api

In this scenario, policies for each location would be defined in IdP Orchestrator App Gateways.

Load-Balancing and Sticky Sessions

Web servers are often load-balanced to distribute traffic and enable high availability. Enable sticky sessions on any load balancers fronting IdP and RP Orchestrators so that the RP Orchestrators can successfully establish sessions for a resource owner via the OIDC flow.

Without session affinity the end user will constantly be redirected to the IdP Orchestrator for authentication, as the requested RP Orchestrator may not have a session cached for the user (even though they have already authenticated).