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 127.0.0.1) 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 {
    listen 127.0.0.1:8080;
    server_name app.myhostname.local;
    location / {
        root /www/app;
        allow 127.0.0.1;
        deny all;
        ...
    }
}

Apache serving on localhost only

Listen 127.0.0.1:8080 http

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

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

App Gateway for a local server

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

appgateways:
  - 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:

fabric:
  consumers:
    - upstream: http://127.0.0.1:8080 
      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
      appgatewayMappings:
        - location: /
          appgatewayName: my-app1
        - location: /downloads
          appgatewayName: downloads-app1
      ignoredPaths:
        - /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).

Kubernetes