Proxy inverse

Il est recommandé de placer à la fois le site FoxIDs et le site FoxIDs Control derrière un proxy inverse.

Proxies inverses

FoxIDs prend généralement en charge tous les proxies inverses ; les proxies suivants ont été testés.

Azure Front Door

Azure Front Door peut être configuré comme proxy inverse. Azure Front Door réécrit les domaines par défaut.

N’activez PAS le cache. L’en-tête Accept-Language n’est pas transmis si le cache est activé. Cet en-tête est requis par FoxIDs pour prendre en charge les cultures.

Ajoutez un endpoint Azure Front Door pour le site FoxIDs et le site FoxIDs Control. Restreindre l’accès en exigeant l’en-tête HTTP X-FoxIDs-Secret.
Désactivez l’affinité de session et configurez éventuellement des politiques WAF.

Cloudflare

Cloudflare peut être configuré comme proxy inverse. Mais Cloudflare nécessite un plan Enterprise pour réécrire les domaines (en-têtes host). Restreindre l’accès en exigeant l’en-tête HTTP X-FoxIDs-Secret.

Azure Application Gateway

Azure Application Gateway peut réécrire tous les domaines si configuré. L’en-tête HTTP X-FoxIDs-Secret peut être ajouté pour restreindre l’accès (recommandé selon l’infrastructure).

Configurez éventuellement une règle de réécriture pour exiger un secret et envoyer un secret dans un en-tête HTTP X-FoxIDs-Secret. Vous pouvez exiger un en-tête X-FoxIDs-Secret si vous avez un proxy inverse devant Azure Application Gateway.
Si un secret est requis, ajoutez une sonde de santé HTTPS personnalisée avec le paramètre de requête X-FoxIDs-Secret /?x-foxids-secret=xxx et le secret.

IIS ARR Proxy

Le proxy Application Request Routing (ARR) d’Internet Information Services (IIS) nécessite un serveur Windows. ARR Proxy réécrit les domaines avec une règle de réécriture. L’en-tête HTTP X-FoxIDs-Secret peut être ajouté pour restreindre l’accès (recommandé selon l’infrastructure).

Une règle globale qui accepte tous les domaines externes peut être configurée. Cet exemple est une règle globale ; des règles peuvent aussi être ajoutées aux sites web.
Vous pouvez à la fois exiger (secret1) et envoyer (secret2) dans un en-tête HTTP X-FoxIDs-Secret. Vous pouvez exiger un en-tête X-FoxIDs-Secret si vous avez un proxy inverse devant le proxy ARR.

<globalRules>
    <rule name="my-rule-name" patternSyntax="Wildcard" stopProcessing="true">
        <match url="*" />
        <conditions>
            <add input="{HTTP_X-FoxIDs-Secret}" pattern="... secret1 ..." ignoreCase="false" />
        </conditions>                                                
        <action type="Rewrite" url="https://my-foxids-installation.com/{R:1}" />
        <serverVariables>
            <set name="HTTP_X-ORIGINAL-HOST" value="{HTTP_HOST}" />
            <set name="HTTP_X-FoxIDs-Secret" value="... secret2 ..." />
        </serverVariables>
    </rule>
</globalRules>

Lire les en-têtes HTTP

Le site FoxIDs prend en charge la lecture de l’adresse IP client transmise dans les en-têtes HTTP suivants par ordre de priorité :

1. CF-Connecting-IP
2. X-Azure-ClientIP
3. X-Forwarded-For

Le site FoxIDs prend en charge la lecture du domaine personnalisé (nom d’hôte) depuis le proxy inverse dans les en-têtes HTTP suivants par ordre de priorité :

1. X-ORIGINAL-HOST
2. X-Forwarded-Host

L’en-tête host n’est lu que si l’accès est restreint par l’en-tête HTTP X-FoxIDs-Secret ou si le paramètre Settings__TrustProxyHeaders est défini sur true.

Le site FoxIDs et le site FoxIDs Control prennent en charge la lecture du schéma HTTP/HTTPS si le paramètre Settings__TrustProxySchemeHeader est défini sur true. Dans les en-têtes HTTP suivants par ordre de priorité :

1. X-Forwarded-Scheme
2. X-Forwarded-Proto

Restreindre l’accès

Les sites FoxIDs et FoxIDs Control peuvent restreindre l’accès en fonction de l’en-tête HTTP X-FoxIDs-Secret.
La restriction d’accès est activée en ajoutant le paramètre Settings__ProxySecret avec le secret.