Ariba changed the web server certificates recently and asked customers to update the new certificate on the ADFS 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.

Note: The old SAML signing certificate for s1.ariba.com expired on August 10th 2017. The new SAML signing certificate with validity until 2020 needs to be imported by Identity Providers.

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 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 Request then customer need to have the new certificate and not an expired certificate of Ariba.

SAP Ariba supports both SHA1 as well as SHA256 certificates from 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 UserID sent from 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