Référence de l’orchestrateur
Déploiements
Serveur Web avec orchestrateur local

Serveur Web avec orchestrateur local

Dans les cas de figure où l’utilisation de l’orchestrateur en tant que proxy de passerelle réseau n’est pas viable en raison de l’absence de fiabilité du réseau (par exemple, les architectures de vérification systématique), l’orchestrateur peut être déployé sur le même hôte que le serveur web de l’application.

Ce modèle est similaire au modèle sidecar utilisé dans les architectures de maillage de services de conteneurs pour restreindre l’accès entre les microservices. L’accès à l’application ou au service n’est autorisé qu’à travers le proxy fonctionnant conjointement avec le serveur web.

Configuration de l’orchestrateur RP (client)

Les orchestrateurs déployés sur le même hôte que le serveur web seront souvent configurés en tant qu’orchestrateur RP (client OIDC), utilisant un orchestrateur IDP central pour fournir l’authentification et la politique. Reportez-vous à la documentation de l’Orchestrateur RP-IDP pour plus de détails.

Configuration du serveur Web

Configurez le serveur web pour qu’il s’exécute sur une interface locale (par exemple, localhost ou 127.0.0.1) en utilisant un port qui n’entre pas en conflit avec l’orchestrateur (par exemple, 8080). L’orchestrateur s’exécutera sur une interface publique de l’hôte, gérant la terminaison TLS et toutes les requêtes autres que celles provenant de l’hôte lui-même.

Dans les exemples suivants, les serveurs Web sont configurés pour :

  • écouter les connexions sur localhost, sur le port 8080 (uniquement)
  • répondre aux demandes de nom de serveur « app.myhostname.local »
  • refuser les accès ne provenant pas de localhost

NGINX ne sert que sur localhost 

server {
    listen 127.0.0.1:8080;
    server_name app.myhostname.local;
    location / {
        root /www/app;
        allow 127.0.0.1;
        deny all;
        ...
    }
}

Apache ne sert que sur localhost 

Listen 127.0.0.1:8080 http

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

Le nom d’hôte app.myhostname.local doit être configuré dans /etc/hosts pour atteindre 127.0.0.1.

Passerelle d’applications pour un serveur local

Si l’orchestrateur adjacent était configuré en tant que proxy autonome, la configuration appgateways correspondante pourrait se présenter comme suit :

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

Si l’orchestrateur adjacent était configuré en tant qu’orchestrateur RP, la configuration fabric correspondante pourrait se présenter comme suit :

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

Dans ce cas de figure, les politiques pour chaque emplacement seraient définies dans les passerelles d’application de l’orchestrateur IDP.

Équilibrage de charge et sessions persistantes

Les serveurs web sont souvent soumis à un équilibrage de charge afin de répartir le trafic et d’assurer une haute disponibilité. Activez les sessions persistantes sur tous les équilibreurs de charge en amont des orchestrateurs IDP et RP afin que les orchestrateurs RP puissent établir avec succès des sessions pour un propriétaire de ressources via le flux OIDC.

Sans affinité de session, l’utilisateur final sera constamment redirigé vers l’orchestrateur IDP pour l’authentification, car l’orchestrateur RP demandé peut ne pas avoir de session mise en cache pour l’utilisateur (même s’il s’est déjà authentifié).

Kubernetes