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