Assurez-vous que le certificat du serveur Web est correct et, lorsqu'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 liaison HTTPS (Hypertext Transfer Protocol Secure) soit terminé et ne soit pas bloqué. Le nouveau certificat Ariba mis à jour 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 de partie utilisatrice en SHA2.

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

Nous pouvons capturer les journaux de deux façons.

1. Nous pouvons activer la journalisation avancée dans le domaine du client > SSO (suivi de connexion unique) 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 > SAML tracer.

Dans les deux modes, nous pouvons identifier si l'ID du nom est différent de l'ID utilisateur dans Ariba.

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

1. Activez Auth: DEBUG, sso: DEBUG and the user: Info for all the UI Nodes.
2. Une fois que l'utilisateur a tenté de se connecter à Ariba via l'authentification unique (SSO). Désactivez les journaux de tous les nœuds d'interface utilisateur d'approvisionnement ou de sourcing et récupérez les fichiers journaux.
3. Dans tous les journaux des nœuds 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 la communauté du client et de l'heure de la tentative de connexion de l'utilisateur, afin de savoir que vous récupérez le bon SAMLResponse.
4. Collez la réponse SAML 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 au 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és.)

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 obligatoire un certificat SHA256 du côté du client.

Vous pourrez le voir dans la demande SAML envoyée depuis 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. Chargez le certificat Ariba pour établir une 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 de partie émettrice sur SHA1.
6. Cliquez sur l'URL (Uniform Resource Locator) pour vérifier si l'authentification de l'utilisateur est réussie.

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 sur Ariba, etc.

Assurez-vous que l'ID utilisateur envoyé par le client correspond à ce qui est stocké dans Ariba comme ID utilisateur. Il 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