IBM Cloud Docs
Pour quelle raison ma demande d'authentification SAML a-t-elle échoué ?

Pour quelle raison ma demande d'authentification SAML a-t-elle échoué ?

Des erreurs liées à votre authentification SAML se produisent.

Pour quelle raison ma signature de message SAML n'est-elle pas validée ?

Lorsque vous testez votre application, vous recevez le message d'erreur suivant :

The SAML message signature could not be validated

Cette erreur se produit lorsqu'App ID ne parvient pas à vérifier la signature envoyée par SAML.

Pour résoudre le problème, vérifiez que l'option Inbound Signature est définie avec la valeur None dans votre configuration.

Pour quelle raison le paramètre RelayState est-il manquant dans ma réponse d'authentification ?

Le paramètre RelayState est manquant dans votre réponse d'authentification.

App ID envoie un paramètre opaque appelé RelayState dans le cadre de la demande d'authentification. Si vous ne voyez pas ce paramètre dans votre réponse, il se peut que votre fournisseur d'identité ne soit pas configuré pour le renvoyer correctement. Le paramètre RelayState a le format suivant.

https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token

Vérifiez que votre fournisseur SAML est configuré pour renvoyer le paramètre RelayState à App ID sans le modifier en aucune façon.

Pour quelle raison une erreur liée à mon ID de nom se produit-elle ?

Lorsque vous envoyez une demande d'authentification, vous recevez une erreur concernant le paramètre NameID.

App ID, en tant que fournisseur de services, définit la manière dont les utilisateurs sont identifiés par le service et par le fournisseur d'identité. Avec App ID, les utilisateurs sont identifiés dans la demande d'authentification NameID dans la zone NameID, comme indiqué dans l'exemple suivant.

<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>

Pour résoudre le problème, assurez-vous que le paramètre NameID de votre fournisseur d'identité est formaté en tant qu'adresse électronique. Vérifiez que tous les utilisateurs de votre registre de fournisseurs d'identité ont un format d'adresse électronique valide. Vérifiez ensuite que la zone NameID est correctement définie de sorte qu'un courrier électronique valide soit toujours renvoyé, même si les utilisateurs de votre registre ont plusieurs courriers électroniques.

Echec du déchiffrement de la réponse

Vous recevez l'un des messages d'erreur suivants en réponse à votre demande d'authentification.

Message d'erreur 1 :

Unexpectedly received an encrypted assertion. Please enable response encryption in your App ID SAML configuration.

Message d'erreur 2 :

Could not decrypt SAML assertion. Ensure your SAML provider is configured with the App ID encryption.

Si votre fournisseur d'identité est configuré pour le chiffrement, App ID doit être configuré pour signer les demandes d'authentification SAML (AuthnRequest). Ensuite, votre fournisseur d'identité doit être configuré pour attendre la configuration correspondante. Vous pourriez recevoir ces erreurs pour l'une des raisons suivantes :

  • App ID n'est pas configuré pour s'attendre à ce que la réponse SAML du fournisseur d'identité soit chiffrée.
  • App ID ne peut pas déchiffrer correctement vos assertions.

Si vous recevez le message d'erreur 1, vérifiez que votre configuration SAML est configurée pour recevoir une réponse chiffrée. Par défaut, App ID ne s'attend pas à ce que la réponse soit chiffrée. Pour configurer le chiffrement, définissez le paramètre encryptResponse sur true à l'aide de l'API.

Si vous recevez le message d'erreur 2, assurez-vous que votre certificat est correct. Vous pouvez obtenir le certificat de signature à partir du fichier XML de métadonnées de App ID. Assurez-vous d'utiliser la clé avec <KeyDescriptor use="signing">. Vérifiez que votre fournisseur d'identité est configuré pour utiliser `` comme algorithme de signature.

Code d'erreur du répondeur

Lorsque vous envoyez une demande d'authentification, vous recevez le message d'erreur générique suivant :

urn:oasis:names:tc:SAML:2.0:status:Responder

Bien que App ID envoie la demande d'authentification initiale, le fournisseur d'identité doit effectuer l'authentification de l'utilisateur et renvoyer la réponse. Plusieurs raisons peuvent amener votre fournisseur d'identité à générer ce message d'erreur.

Le message peut s'afficher si votre fournisseur d'identité :

  • Ne parvient pas à trouver ou vérifier le nom d'utilisateur
  • Ne prend pas en charge le format NameID défini dans la demande d'authentification (AuthnRequest).
  • Ne prend pas en charge le contexte d'authentification.
  • Nécessite que la demande d'authentification soit signée ou utilise un algorithme spécifique dans la signature.

Pour résoudre le problème, vérifiez votre configuration et votre nom d'utilisateur. Vérifiez que le contexte d'authentification et les variables définies sont corrects. Vérifiez si votre demande doit être signée d'une manière spécifique.

Demande d'authentification non prise en charge

Vous recevez un message concernant une demande d'authentification non prise en charge.

Lorsque App ID génère une demande d'authentification, il peut utiliser le contexte d'authentification pour demander la qualité de l'authentification et des assertions SAML.

Pour résoudre le problème, vous pouvez mettre à jour votre contexte d'authentification. Par défaut, App ID utilise la classe d'authentification urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport et la comparaison exact. Vous pouvez mettre à jour le paramètre de contexte pour l'adapter à votre cas d'utilisation à l'aide des API.

Echec de signature de la demande SAML

Vous recevez une erreur qui indique qu'une demande d'authentification ne peut pas être vérifiée.

App ID peut être configuré pour signer la demande d'authentification SAML (AuthNRequest), mais votre fournisseur d'identité doit être configuré pour recevoir la configuration correspondante.

Pour résoudre le problème, procédez comme suit :

  • Vérifiez qu'IBM Cloud est configuré pour signer la demande d'authentification en réglant le paramètre signRequest sur true à l'aide de l'API set SAML IdP. Vous pouvez vérifier si votre demande d'authentification est signée en regardant l'URL de la demande. La signature est incluse comme paramètre de requête. Par exemple, https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&SigAlg=value&Signature=value&RelayState=token

  • Vérifiez que votre fournisseur d'identité est configuré avec le bon certificat. Pour obtenir le certificat de signature, vérifiez le fichier XML de métadonnées IBM Cloud que vous avez téléchargé à partir du tableau de bord IBM Cloud. Assurez-vous d'utiliser la clé avec <KeyDescriptor use="signing">.

  • Vérifiez que votre fournisseur d'identité est configuré pour utiliser `` comme algorithme de signature.

Pourquoi ma méthode d'authentification ne correspond-elle pas?

Vous recevez un message indiquant que la méthode d'authentification fournie ne correspond pas à la méthode d'authentification demandée.

Exemple :

AADSTS75011: Authentication method ‘X509, Multifactor, X509Device’ by which the user authenticated with the service doesn't match requested authentication method 'Password, ProtectedTransport'.

Lorsque App ID génère une demande d'authentification, le contexte d'authentification est utilisé pour demander la qualité de l'authentification et des assertions SAML.

Par défaut, App ID utilise les comparaisons urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport et exact dans authnContext, comme indiqué dans Understanding SAML, alors que vous essayez d'utiliser une méthode d'authentification différente. Dans l'exemple fourni, la méthode d'authentification X509, Multifactor est utilisée.

Pour résoudre ce problème, vous pouvez mettre à jour votre contexte d'authentification pour les valeurs class et comparison dans SAML authnContext. Pour mettre à jour le paramètre de contexte en fonction de votre cas d'utilisation, vous pouvez utiliser l'API.

Vous pouvez également définir une adresse authnContext vide dans votre configuration SAML, comme le montre l'exemple suivant.

  "authnContext": { }