Migration SAML pour les domaines personnalisés

Migrez votre connexion de fédération SAML existante d’un domaine personnalisé Auth0 hérité vers un nouveau domaine personnalisé Auth0, afin de permettre à vos tenants de tirer parti des capacités de Multiple Custom Domain (MCD).

Migrez votre connexion de fédération SAML existante d’un domaine personnalisé Auth0 hérité vers un nouveau domaine personnalisé, afin de permettre à vos tenants de tirer parti des capacités Multiple Custom Domain (MCD).

Les fournisseurs d’identité externes (IdP) sont souvent codés en dur pour utiliser votre ancien domaine, ce qui vous oblige à déployer un proxy inverse intelligent qui intercepte la réponse SAML envoyée à votre ancien domaine et la redirige de façon sécurisée vers un nouveau domaine personnalisé.

Cela assure une migration fluide pour les utilisateurs fédérés, vous permettant d’utiliser immédiatement votre nouveau domaine sans avoir à attendre les mises à jour de configuration obligatoires de votre IdP.

​

Prérequis

Ce processus exige une configuration avec Terraform pour mettre en place les composants Auth0 et le déploiement d’un Cloudflare Worker pour la logique de proxy.

Avant d’entamer votre migration, consultez les exigences ci-dessous :

• Un tenant avec un plan Enterprise et MCD activé.
• Deux domaines personnalisés vérifiés configurés dans votre tenant Auth0 :
  1. Ancien domaine hérité (pour le proxy)
  2. Nouveau domaine cible (pour l’application)
• Terraform CLI et Node.js/npm installés.
• Un compte Cloudflare avec accès au domaine qui héberge vos domaines personnalisés.

​

Fonctionnement

Cette stratégie de migration utilise un proxy inverse intelligent pour faire la transition entre votre ancien domaine personnalisé et votre nouveau domaine. Ce proxy est déployé sur l’ancien domaine afin d’intercepter la réponse d’authentification SAML envoyée par votre fournisseur d’identité (IdP) externe.

Cela est nécessaire, car la configuration de l’IdP est codée en dur pour le endpoint de votre ancien domaine. Le proxy modifie les champs de contrôle de la charge utile SAML (comme Destination et Recipient) afin qu’ils correspondent correctement au nouveau domaine personnalisé.

Enfin, le proxy transmet cette charge utile corrigée au endpoint de connexion du nouveau domaine. Cela permet un basculement sans interruption vers votre nouveau domaine, sans nécessiter de changements de configuration manuels de la part de vos partenaires IdP.

​

Préparation et configuration

Pour préparer et configurer votre migration :

1. Clonez le dépôt de migration :

git clone https://github.com/abbaspour/auth0-mcd-federation-migration.git
cd auth0-mcd-federation-migration

2. Installez les dépendances :

npm install

3. Créez un fichier terraform.auto.tfvars dans votre répertoire tf avec les identifiants requis et les informations sur le domaine :

# Variables du fournisseur de services (SP) Auth0
auth0_domain = "your-sp-tenant.auth0.com"
auth0_existing_custom_domain = "oldfed.example.com"
auth0_new_custom_domain = "id.example2.com"
auth0_tf_client_id = "your-sp-client-id"
auth0_tf_client_secret = "your-sp-client-secret"

# Variables du fournisseur d'identité (IDP) Auth0
auth0_idp_domain = "your-idp-tenant.auth0.com"
auth0_idp_tf_client_id = "your-idp-client-id"
auth0_idp_tf_client_secret = "your-idp-client-secret"

# Variables Cloudflare
cloudflare_api_key = "your-cloudflare-api-key"
cloudflare_email = "your-cloudflare-email"
cloudflare_zone_id = "your-cloudflare-zone-id"

4. Initialisez et appliquez Terraform :

cd tf
terraform init
terraform apply

Cela crée l’application et la connexion SAML nécessaires, configure le DNS dans Cloudflare et prépare les variables d’environnement pour le worker.

​

Déployer le Cloudflare Worker

Ce proxy gère l’interception de la réponse SAML et la logique de redirection. Pour le déployer :

1. Déployez le proxy Cloudflare :

cd ..
npx wrangler deploy

2. Le worker reçoit automatiquement les variables d’environnement requises (comme AUTH0_EDGE_LOCATION et NEW_SP_DOMAIN) à partir de la sortie de Terraform.

​

Mettre temporairement à jour les paramètres de la connexion SAML

Votre ancien domaine reçoit la réponse SAML avant qu’elle ne soit renvoyée au nouveau domaine. Par conséquent, les paramètres de validation attendus de la connexion SAML doivent temporairement pointer vers l’URL de rappel de l’ancien domaine afin d’éviter les erreurs de non-correspondance.

1. Obtenez un jeton d’accès à la Management API pour le tenant de votre fournisseur de services, avec les portées read:connections et update:connections :

   cd bin/
   export access_token='<sp-tenant-management-api-token>'
   

2. Mettez à jour l’URL de destination :

   ./sp-set-destination-url.sh -i <saml-connection-id> -d https://oldfed.example.com/login/callback
   

3. Mettez à jour l’URL du destinataire :

   ./sp-set-recipient-url.sh -i <saml-connection-id> -r https://oldfed.example.com/login/callback