Identité managée & Fédération d'identité

Mise en œuvre de l'identité managée Power Platform (V2)

❓ 1. QUOI ? (De quoi s'agit-il ?)

C'est la mise en place d'une passerelle de confiance sécurisée (Fédération d'Identité - FIC) entre le cloud Power Platform (SaaS) et votre infrastructure Azure.

🎯 2. POURQUOI ? (Quel est le but et le bénéfice ?)

👥 3. QUI ? (Qui fait quoi ? Matrice des rôles)

Le travail est strictement séparé pour que chacun reste dans son domaine d'expertise :

🔐 4. LE CERTIFICAT (Comment le créer et le fournir ?)

Le certificat ne sert pas à s'authentifier auprès du portail Azure (l'UAMI s'en charge sans secret). Il sert uniquement au développeur pour signer son code afin de prouver son identité. En entreprise, c'est au Sysadmin de le générer pour garder le contrôle des clés.

🧪 Option A : Méthode rapide pour le Déploiement / Test (Script PowerShell)

À exécuter dans une console PowerShell en tant qu'administrateur pour générer un certificat auto-signé :

# 1. Génération du certificat de signature de code
\$cert = New-SelfSignedCertificate `
    -Type "CodeSigningCert" `
    -Subject "CN=Certificat-Plugin-PowerPlatform-Dev" `
    -KeyExportPolicy "Exportable" `
    -KeyLength 2048 `
    -CertStoreLocation "cert:\CurrentUser\My" `
    -NotAfter (Get-Date).AddYears(1)

# 2. Définition d'un mot de passe sécurisé pour le fichier PFX
\$password = ConvertTo-SecureString "MettreUnMotDePasseFortIci123!" -AsPlainText -Force

# 3. Exportation du certificat au format .pfx (contenant la clé privée)
\(cert \vert{} Export-PfxCertificate -FilePath "C:\Certificats\PluginSignCert.pfx" -Password \)password

🔒 Option B : Méthode pour la Production (PKI d'entreprise / ADCS)

  1. Dupliquer le modèle par défaut Signature de code (Code Signing) sur votre serveur CA.
  2. Dans l'onglet Request Handling, cocher impérativement Allow private key to be exported (Autoriser l'exportation de la clé privée).
  3. Demander le certificat via la console mmc locale de votre poste de gestion.
  4. Exporter le certificat obtenu au format .PFX (inclure la clé privée) avec un mot de passe fort, puis le transmettre au développeur.
  5. Rappel : Notez bien la date d'expiration dans votre calendrier pour anticiper le renouvellement du fichier côté dev.

📍 5. OÙ ? (Où est-ce que ça se configure et se gère ?)

Toute votre partie se gère dans le Portail Azure et dans Microsoft Entra ID :

  1. Création de l'UAMI : Dans votre groupe de ressources Azure (comme une VM classique).
  2. Configuration du FIC : Directement à l'intérieur de votre ressource UAMI, dans l'onglet Informations d'identification fédérées.
  3. Attribution des droits : Sur la ressource finale (ex: dans l'onglet Contrôle d'accès (IAM) de votre Azure Key Vault).
  4. Supervision et Logs : Dans Microsoft Entra ID > Applications d'entreprise (en pensant à filtrer le type d'application sur Identités managées). C'est là que vous verrez les logs de connexion pour le troubleshooting.

⚙️ 6. COMMENT ? (Quelles sont les étapes clés pour vous ?)

Pour réussir le déploiement sans encombre, suivez ce fil conducteur :

  1. Créer l'UAMI (via le portail ou en une ligne Azure CLI) et donner son Client ID au développeur.
  2. Fournir le certificat (généré à l'Étape 4) au développeur pour qu'il signe son code.
  3. Récupérer les billes du développeur une fois son code signé : il doit vous donner son ID d'environnement Power Platform et les hachages de son certificat.
  4. Créer le lien FIC dans l'UAMI en renseignant scrupuleusement la chaîne d'identification V2 : /eid1/c/pub/t/{tenantId}/a/qzXoWDkuqUa3l6zM5mM0Rw/n/plugin/e/{environmentId}/i/{issuerHash}/s/{subjectHash}
  5. Donner les droits RBAC (ex: rôle Utilisateur des secrets de Key Vault) à l'UAMI sur votre ressource Azure.
  6. En cas de pépin (Erreur AADSTS700213) : Pas de panique, cela signifie simplement que la longue chaîne textuelle du FIC au point n°4 contient une erreur de casse, un espace en trop ou un mauvais hachage. Il suffit de la vérifier avec le développeur.