Configuration SAML 2.0
Configurez l'authentification unique en utilisant SAML 2.0 pour les fournisseurs d'identité qui prennent en charge le protocole SAML. Ce guide couvre la configuration SAML générique applicable à tout IdP conforme.
Prérequis
- Un fournisseur d'identité conforme SAML 2.0 (Okta, Azure AD, OneLogin, PingFederate, etc.)
- Accès administrateur à votre fournisseur d'identité pour créer et configurer des applications
- Un compte Administrateur de l'organisation SecureCodingHub
Détails du fournisseur de services
Ces valeurs sont nécessaires lors de la configuration de SecureCodingHub dans votre fournisseur d'identité :
| Paramètre | Valeur |
|---|---|
| SP Entity ID | https://api.limeplate.com |
| URL ACS (Assertion Consumer Service) | https://api.limeplate.com/api/sch/auth/sso/callback/saml |
| URL de métadonnées SP | https://api.limeplate.com/api/sch/auth/sso/metadata |
| Format Name ID | urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress |
| Binding | HTTP-POST |
Étape 1 — Configurer votre fournisseur d'identité
Étape 2 — Configurer SAML dans SecureCodingHub
Étape 3 — Tester
Mappage d'attributs
SecureCodingHub lit les attributs suivants de l'assertion SAML :
| Attribut SAML | Champ SecureCodingHub | Requis |
|---|---|---|
NameID (format e-mail) | Oui | |
givenName (…/claims/givenname) | Nom (première partie — concaténée avec le nom de famille en un nom d'affichage unique) | Non |
surname (…/claims/surname) | Nom (deuxième partie — jointe avec givenName au moment du provisionnement) | Non |
Lire une réponse SAML dans la nature
Lorsque SAML échoue, le chemin le plus rapide vers un diagnostic est d'inspecter la réponse SAML réelle plutôt que le symptôme dans le navigateur. Installez une extension de navigateur SAML tracer, reproduisez la connexion en échec et regardez le POST que l'IdP envoie à l'URL ACS. Trois champs vous disent presque tout. L'élément Issuer devrait correspondre à l'entityID publié dans vos métadonnées IdP. L'élément Audience imbriqué dans Conditions devrait correspondre au SP Entity ID configuré dans SecureCodingHub. Le NameID du sujet devrait être l'adresse e-mail de l'utilisateur au format que vous avez spécifié.
Au-delà de ces champs, vérifiez l'identifiant InResponseTo si votre IdP le prend en charge, confirmez que la réponse est signée (l'élément ds:Signature est présent), et vérifiez que les horodatages NotBefore et NotOnOrAfter sont cohérents avec l'horloge actuelle. Un décalage horaire significatif entre IdP et SP cause le rejet silencieux d'assertions par ailleurs valides. Si la réponse semble bien formée mais que l'assertion est toujours rejetée, copiez la valeur SAMLResponse encodée en base64 du tracer et décodez-la hors ligne. Lire le XML brut par rapport à la spécification SAML 2.0 est le moyen le plus fiable de trouver un attribut manquant ou une déclaration mal configurée.
Quand demander de l'aide à l'équipe IdP versus l'équipe SP
La plupart des tickets de support SAML peuvent être triés en moins d'une minute si vous savez de quel côté de la fédération vit l'erreur. En règle générale, les non-correspondances d'audience et d'émetteur sont des problèmes côté SP : la configuration SecureCodingHub attend des valeurs que l'IdP ne produit pas, ou elle a été configurée contre un SP entity ID différent de celui pour lequel l'IdP signe. Ceux-ci sont résolus en ajustant les paramètres SSO SecureCodingHub ou le SP Entity ID et l'URL ACS dans la configuration d'application IdP. Contactez d'abord le côté SecureCodingHub.
Les problèmes de revendication et de mappage d'attributs sont généralement côté IdP. Si les utilisateurs atterrissent dans SecureCodingHub avec des prénoms manquants, des adresses e-mail erronées ou des attributions de rôle inattendues, l'IdP émet des attributs que le SP ne peut pas consommer. L'administrateur IdP doit ajouter ou renommer les revendications dans la configuration d'application. Les échecs de certificat et de signature sont partagés : si le certificat IdP a expiré ou a été tourné, c'est une correction côté IdP. Si SecureCodingHub a cessé de faire confiance à une signature précédemment valide, les métadonnées ou le certificat stocké côté SP est devenu obsolète et doit être rafraîchi. En cas de doute, capturez la sortie du tracer SAML et partagez-la avec les deux équipes ; la réponse elle-même montre quel côté possède la prochaine action. Voir la Vue d'ensemble SSO pour des conseils de sélection de protocole.
SAML 2.0 : questions fréquentes
Que signifie réellement « SAML fédéré » ?
SAML fédéré fait référence à la relation de confiance établie entre un fournisseur d'identité (IdP) et un fournisseur de services (SP) pour qu'un utilisateur puisse s'authentifier une fois chez l'IdP et que cette assertion soit acceptée par le SP. La fédération est le contrat XML signé : chaque côté fait confiance aux métadonnées et au certificat de signature de l'autre. SecureCodingHub fait partie de votre fédération une fois que vous téléchargez les métadonnées IdP et que l'IdP connaît le SP entity ID.
Comment faire tourner un certificat SAML sans casser les connexions ?
Une rotation de certificat SAML s'exécute mieux avec une brève fenêtre de chevauchement. Si votre IdP prend en charge la publication de plusieurs certificats de signature dans les métadonnées, ajoutez le nouveau certificat avant de retirer l'ancien et faites recharger les métadonnées IdP à SecureCodingHub pour que les deux certificats soient de confiance pendant le basculement. Après que l'IdP commence à signer avec la nouvelle clé, surveillez les connexions pendant un jour, puis retirez l'ancien certificat des métadonnées. La panne de production la plus courante est de faire tourner sans chevauchement, un vendredi.
SAML vs OAuth vs OpenID Connect — lequel choisir ?
Lorsque les équipes comparent SAML vs OAuth vs OpenID Connect, la réponse pratique est de suivre l'adéquation opérationnelle. SAML 2.0 est le standard de fédération mature, basé sur XML, dominant dans les IdP d'entreprise comme ADFS et PingFederate. OAuth 2.0 seul est un cadre d'autorisation, non d'authentification. OpenID Connect superpose l'identité par-dessus OAuth 2.0 et est le défaut moderne pour Azure AD et Okta. SAML ou OIDC vous donneront une sécurité SSO équivalente avec SecureCodingHub.
Comment décoder une réponse SAML pour dépanner un échec ?
Pour décoder une réponse SAML, capturez le paramètre SAMLResponse encodé en base64 que l'IdP poste à l'URL ACS — une extension de navigateur SAML tracer est le moyen le plus simple de le saisir. Décodez la valeur en base64 vers du XML brut et inspectez Issuer, Audience, NameID et les horodatages. La plupart des échecs se résolvent une fois que vous comparez ces quatre champs aux valeurs configurées dans les paramètres SSO SecureCodingHub et la configuration d'application de votre IdP.