Assurez-vous que le certificat du serveur Web est correct et, chaque fois qu'une mise à jour du certificat est effectuée, Ariba demande aux clients de mettre à jour le nouveau certificat sur leur serveur IdP afin que l'établissement de la liaison HTTPS (Hypertext Transfer Protocol Secure) soit terminé et ne soit pas bloqué. Le nouveau certificat mis à jour par Ariba est de type SHA2 (Secure Hash Algorithm 2, 256 bits). Dans ce cas, le client a mis à jour le nouveau certificat sur son serveur ADFS et a également modifié l'algorithme de hachage sécurisé à utiliser pour cette relation de confiance avec la partie utilisatrice SHA2.

Dans un autre cas, le client n'a pas mis à jour le nouveau certificat de signature Ariba et dispose toujours de l'ancien certificat, qui a expiré.

Nous pouvons capturer les journaux de deux façons.

1. Nous pouvons activer la connexion avancée dans le domaine du client > SSO (Single Sign-On tracing) et Auth (demandes d'authentification), puis demander au client de reproduire l'erreur.
2. Capturez les journaux à l'aide d'un plug-in Google Chrome externe > traceur SAML.

Dans les deux modes, nous pouvons identifier si le NameID est différent de UserID dans Ariba.

Étapes de capture et de récupération des journaux :

1. Activez Auth : DEBUG, sso : DEBUG et l'utilisateur : Info pour tous les nœuds IU.
2. Une fois que l'utilisateur a tenté de se connecter à Ariba via l'authentification unique (SSO). Désactivez les journaux sur tous les nœuds d'IU d'approvisionnement ou de sourcing et récupérez les fichiers journaux.
3. Sur tous les journaux de nœuds d'IU, recherchez (Ctrl+F) SAMLResponse et copiez toute la ligne SAMLResponse du fichier journal (où qu'il se trouve). Veillez à prendre note du nœud de communauté du client et de l'heure de la tentative de connexion de l'utilisateur, afin que vous sachiez que vous récupérez la bonne réponse SAMLResponse.
4. Collez la SAMLResponse comme indiqué ci-dessous sur Notepad++ et recherchez la balise <NameID> et voyez quel ID utilisateur est transmis dans la réponse SAML.

En outre, nous pouvons également voir les points de réponse SAML pour le problème de signature.

</ds:Signature><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder"/><samlp:StatusMessage>Impossible de vérifier la signature</samlp:StatusMessage></samlp:Status></samlp:Response>

Le nouveau certificat mis à jour sur nos serveurs web est de l'algorithme SHA256 (Secure Hash Algorithm 2, 256 bits). Cependant, nous générons toujours des signatures avec SHA1 et non SHA256. (Notez que les autorités de certification ne fourniront pas de nouveaux certificats SHA1, car la plupart des navigateurs traitent les sites avec un certificat SHA1 comme non sécurisé.)

Si l'authentification unique pour le domaine est configurée pour envoyer des demandes SAML, le client doit disposer du nouveau certificat et non d'un certificat Ariba expiré.

SAP Ariba prend en charge les certificats SHA1 et SHA256 du client (fournisseur d'identités) et ne rend pas le certificat SHA256 obligatoire côté client.

Vous pourrez le voir dans la demande SAML envoyée par SAP Ariba. Par exemple :

<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"

Pour corriger ce problème, l'équipe informatique du client doit suivre les étapes ci-dessous :

1. Téléchargez le certificat Ariba pour l'établissement de la liaison ou la relation de confiance.
2. Ouvrez le point de terminaison défini pour Ariba dans ADFS.
3. Accédez à la page Propriétés Ariba.
4. Cliquez sur l'onglet Avancé.
5. Définissez Spécifiez l'algorithme de hachage sécurisé à utiliser pour cette relation de confiance avec la partie utilisatrice sur SHA1.
6. Cliquez sur Uniform Resource Locator (URL) pour vérifier si l'authentification de l'utilisateur a réussi.

L'utilisateur n'existe pas. L'erreur peut également apparaître pour de nombreuses autres raisons, telles que le certificat ne correspondant pas aux deux extrémités, le format NameId ne correspondant pas aux deux extrémités, l'utilisateur étant inactif dans le système Ariba, le compte utilisateur n'existant pas dans Ariba, etc.

Assurez-vous que l'ID utilisateur envoyé par le client correspond à ce qui est stocké dans Ariba en tant qu'ID utilisateur. Ceci est sensible à la casse.

Achats
Contrats stratégiques
Services d'applications d'approvisionnement > Framework d'application > Authentification unique
Sourcing stratégique
Supplier Information and Performance Management