Configuration Azure AD (OIDC)
Guide pas-à-pas pour configurer l'authentification unique avec Microsoft Entra ID (Azure AD) en utilisant OpenID Connect.
Prérequis
- Tenant Azure AD avec accès administrateur
- Compte administrateur d'organisation SecureCodingHub
- Domaine de l'organisation vérifié dans SecureCodingHub
Étape 1 — Enregistrer une application dans Azure AD
Allez dans Azure Portal → Microsoft Entra ID → App registrations → New registration
Nom : SecureCodingHub SSO
Types de compte pris en charge : Accounts in this organizational directory only
URI de redirection : Web → https://api.limeplate.com/api/sch/auth/sso/callback/oidc
Cliquez sur Register
Étape 2 — Créer un secret client
Allez dans Certificates & secrets → New client secret
Description : SecureCodingHub
Expiration : choisissez votre politique (recommandé : 24 mois)
Copiez la valeur du secret immédiatement — elle n'est affichée qu'une seule fois
Étape 3 — Noter vos identifiants
Collectez les valeurs suivantes depuis votre application Azure AD. Vous en aurez besoin à l'étape suivante.
| Paramètre | Où trouver |
|---|---|
| Application (Client) ID | Page Overview |
| Directory (Tenant) ID | Page Overview |
| Client Secret | Certificates & secrets |
| URL de découverte | https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration |
Étape 4 — Configurer SSO dans SecureCodingHub
Connectez-vous en tant qu'Administrateur de l'organisation → Paramètres SSO
Protocole : OIDC
Entity ID / Client ID : collez votre Application ID
URL Discovery / Metadata : collez votre URL de configuration OpenID
Client Secret : collez le secret
Activer SSO
Cliquez sur Enregistrer
Étape 5 — Tester
Ouvrez une fenêtre de navigateur incognito/privée
Allez à la connexion SecureCodingHub
Saisissez une adresse e-mail avec le domaine de votre organisation
Vous devriez être redirigé vers la connexion Microsoft
Après l'authentification, vous devriez être connecté à SecureCodingHub
Pièges SAML Azure AD courants
Lorsque SAML est utilisé avec Azure AD au lieu d'OIDC, trois modes d'échec représentent la plupart des incidents de production. Le premier est un entity ID non correspondant. Azure AD acceptera toute chaîne dans le champ Identifier du panneau SSO, mais si elle ne correspond pas exactement au SP Entity ID configuré dans SecureCodingHub, la réponse SAML est rejetée avec une erreur de restriction d'audience. Copiez l'identifiant depuis la page des paramètres SSO SecureCodingHub directement, ne le tapez pas. Les barres obliques finales et les non-correspondances de protocole (http versus https) sont des échecs silencieux courants.
Le deuxième piège est une non-correspondance d'URI d'émetteur de revendication. Azure AD signe les assertions avec l'URL de métadonnées de fédération qu'il publie, et SecureCodingHub valide que l'émetteur dans la réponse SAML correspond à l'émetteur dans les métadonnées. Si vous changez de tenant, régénérez des certificats ou copiez une URL de métadonnées d'une autre application, l'émetteur divergera et chaque connexion échouera avec une erreur de signature invalide. Le troisième piège est le dimensionnement des revendications de groupe. Azure AD tronque les revendications de groupe lorsque l'assertion dépasse la charge utile maximale, remplaçant les groupes par une référence de point de terminaison graph. Si vous comptez sur les revendications de groupe pour le mappage de rôle en aval, configurez Azure AD pour n'émettre que les groupes attribués à l'application plutôt que tous les groupes auxquels l'utilisateur appartient.
Comment vérifier que SSO fonctionne de bout en bout
La vérification de bout en bout se fait en trois étapes. Premièrement, ouvrez une fenêtre incognito et commencez la connexion depuis la page de connexion SecureCodingHub en utilisant une adresse e-mail d'entreprise. Le navigateur devrait rediriger vers login.microsoftonline.com, présenter l'expérience de connexion Microsoft, puis rediriger vers SecureCodingHub. Si la redirection retour échoue, capturez la barre d'URL au moment de l'échec. Le code d'erreur dans la chaîne de requête est la pièce de preuve la plus utile.
Deuxièmement, confirmez que l'utilisateur atterrit dans la bonne organisation et le bon tableau de bord. Une connexion réussie avec une page d'accueil vide ou une redirection vers la mauvaise organisation pointe généralement vers un mappage de domaine d'organisation manquant. Troisièmement, déconnectez-vous, reconnectez-vous et vérifiez que la deuxième connexion est silencieuse ou quasi-silencieuse. Le cookie de session Microsoft devrait rendre le deuxième flux quasi invisible. Si les deux connexions nécessitent une ré-authentification complète, votre application IdP utilise une politique de session qui empêche la réutilisation du cookie d'authentification unique. Pour les étapes de dépannage partagées, voir le Guide de configuration SAML.