Web server with local orchestrator

For scenarios where using the Orchestrator as a central 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.

Orchestrator Configurations

Orchestrators deployed on the same host as the web server will often be configured as an OIDC client and will use a central IdP Orchestrator to provide authentication and policy. This deployment pattern is often used when a legacy web access management product such as SiteMinder or OAM is being replaced. To learn more about the network topology of this pattern, please see the deployment patterns topic.

Local Proxy Orchestrator

When the adjacent Orchestrator is configured as a proxy, the corresponding proxy app configuration will look like the below. Note how the exampleApp uses the idpOrchestrator as its IDP. Also note that although the app defines its own headers config and authorization policy, it does not handle authenticating against a federated IDP nor does it handle post-authentication attribute loading.

apps:
  - name: exampleApp
    type: proxy
    routePatterns:
      - app.example.com
    upstream: https://app-internal.example.com
    headers:
      - name: SM_USER
        value: "{{ idpOrchestrator.email }}"
      - name: firstName
        value: "{{ idpOrchestrator.given_name }}"
      - name: lastName
        value: "{{ idpOrchestrator.family_name }}"
    policies:
      - location: /
        authentication:
          idps:
            - idpOrchestrator
        authorization:
          allowAll: false

connectors:
  - name: idpOrchestrator
    type: oidc
    # ...

IDP Orchestrator

In this configuration, a separate Orchestrator acts as an OIDC IDP for the “local proxy Orchestrator”. Note how the IDP Orchestrator is responsible for authenticating against a federated IDP (Okta) and it is also responsible for loading attributes (LDAP) post-authentication. The claims returned from Okta and the attributes returned from LDAP are then mapped into the OIDC ID token that will be consumed by the proxy Orchestrator.

apps:
  - name: exampleApp
    type: oidc
    clientID: exampleClientID
    credentials:
      secrets:
        - <exampleClientSecret>
    # ...
    authentication:
      idps:
        - okta
    attrProviders:
      - connector: ldap
        usernameMapping: okta.email
    claimsMapping:
      email: okta.email
      given_name: ldap.givenname
      family_name: ldap.sn

connectors:
  - name: okta
    type: okta
    # ...

  - name: ldap
    type: ldap
    # ...

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.

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).