Ensure the web server certificate is correct, and whenever a certificate update is performed, Ariba asks customers to update the new certificate on their IdP server so that the Hypertext Transfer Protocol Secure (HTTPS) handshake would be complete and is not blocked. The new certificate Ariba updated is of type SHA2 (Secure Hash Algorithm 2, 256 bits). In this case, the customer updated the new certificate on their ADFS server and also changed the secure hash algorithm to use for this relying party trust to SHA2.

In another case, the customer did not update the new Ariba signing certificate and still has the old certificate, which is expired.

We can capture the logs in two ways.

1. We can enable advanced logging in the client's realm > SSO (Single Sign-On tracing) and Auth (Authentication requests), and after that ask the customer to reproduce the error.
2. Capture logs using an external google chrome plugin > SAML tracer.

In both modes we can identify if the NameID is different from the UserID in Ariba.

Steps to capture and retrieve logs:

1. Turn on Auth: DEBUG, sso: DEBUG and the user: Info for all the UI Nodes.
2. After the user attempts to sign in to Ariba via Single Sign-On(SSO). Turn off the logs on all procurement or sourcing UI nodes and retrieve the log files.
3. On all the UI nodes logs, search (Ctrl+F) for SAMLResponse and copy out the entire SAMLResponse line from the log file (wherever it is found). Be sure to take note of the customer's community node and time of the user's login attempt, so you will know you are retrieving the right SAMLResponse.
4. Paste the SAMLResponse as seen below on Notepad++ and search for <NameID> Tag and see what User ID is passed in the SAML Response.

Additionally, we can also see SAML Response points to Signature issue.

</ds:Signature><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder"/><samlp:StatusMessage>Unable to verify the signature</samlp:StatusMessage></samlp:Status></samlp:Response>

The new certificate updated on our web servers is of the SHA256 algorithm (Secure Hash Algorithm 2, 256 bits). However, we still generate signatures with SHA1 and not SHA256. (Note that certificate authorities will not provide new SHA1 certificates, as most of the browsers treat sites with an SHA1 certificate as insecure.)

If SSO for the realm is configured to send SAML requests, then the customer needs to have the new certificate and not an expired certificate of Ariba.

SAP Ariba supports both SHA1 and SHA256 certificates from the customer (Identity Provider) and does not make an SHA256 certificate mandatory on the customer side.

You will be able to see that in the SAML request sent from SAP Ariba. For Example:

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

In order to correct this issue, the customer's Information Technology (IT) team needs to follow below steps:

1. Upload the Ariba certificate for handshake or Trust.
2. Open the end-point set for Ariba in ADFS.
3. Go to the Ariba Properties page.
4. Click the Advanced tab.
5. Set Specify the secure hash algorithm to use for this relying party trust to SHA1.
6. Click the Uniform Resource Locator (URL) to check if user authentication is successful.

The user does not exist. error may also appear for many other reasons, such as the certificate not matching on both ends, the NameId format not matching on both ends, User being inactive in Ariba system, User account not existing on Ariba, etc.

Make sure that the UserID sent from the customer matches what is stored in Ariba as the UserID. This is case-sensitive.

Procurement Application Services > Application Framework > Single Sign-On
Purchasing
Strategic Contracts
Strategic Sourcing
Supplier Information & Performance Management