Assicurarsi che il certificato del server Web sia corretto e, ogni volta che viene eseguito un aggiornamento del certificato, Ariba chiede ai clienti di aggiornare il nuovo certificato sul proprio server IdP in modo che l'handshake HTTPS (Hypertext Transfer Protocol Secure) sia completo e non sia bloccato. Il nuovo certificato Ariba aggiornato è di tipo SHA2 (Secure Hash Algorithm 2, 256 bits). In questo caso, il cliente ha aggiornato il nuovo certificato sul proprio server ADFS e ha anche modificato l'algoritmo di hash sicuro da utilizzare per questa relazione di trust con SHA2.

In un altro caso, il cliente non ha aggiornato il nuovo certificato di firma Ariba e dispone ancora del certificato precedente, scaduto.

Possiamo acquisire i registri in due modi.

1. È possibile abilitare la registrazione avanzata nel realm del client > SSO (monitoraggio Single Sign-On) e Auth (richieste di autenticazione), dopodiché chiedere al cliente di riprodurre l'errore.
2. Acquisire i registri utilizzando un plug-in Google Chrome esterno > SAML tracer.

In entrambe le modalità possiamo identificare se il NameID è diverso dall’ID utente in Ariba.

Passi per acquisire e recuperare i registri:

1. Attivare Auth: DEBUG, sso: DEBUG e l'utente: Info per tutti i nodi UI.
2. Dopo che l'utente ha tentato di accedere ad Ariba tramite Single Sign-On (SSO). Disattivare i registri in tutti i nodi dell'interfaccia utente di approvvigionamento o determinazione della fonte d'acquisto e recuperare i file di registro.
3. In tutti i registri dei nodi UI, cercare (Ctrl+F) SAMLResponse e copiare l'intera riga SAMLResponse dal file di registro (ovunque si trovi). Assicurarsi di prendere nota del nodo della comunità del cliente e dell'ora del tentativo di accesso dell'utente, in modo da sapere che si sta recuperando la SAMLResponse corretta.
4. Incollare SAMLResponse come mostrato di seguito in Notepad++ e cercare il tag <NameID> e vedere quale ID utente viene trasferito nella risposta SAML.

Inoltre, possiamo anche vedere i punti di risposta SAML al problema della firma.

</ds:Signature><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder"/><samlp:StatusMessage>Impossibile verificare la firma</samlp:StatusMessage></samlp:Status></samlp:Response>

Il nuovo certificato aggiornato sui nostri server web è dell'algoritmo SHA256 (Secure Hash Algorithm 2, 256 bits). Tuttavia, si generano ancora firme con SHA1 e non con SHA256. (Tenere presente che le autorità di certificazione non forniranno nuovi certificati SHA1, poiché la maggior parte dei browser tratta i siti con un certificato SHA1 come non sicuri).

Se l'SSO per il realm è configurato per l'invio di richieste SAML, il cliente deve disporre del nuovo certificato e non di un certificato Ariba scaduto.

SAP Ariba supporta entrambi i certificati SHA1 e SHA256 del cliente (Identity Provider) e non rende obbligatorio un certificato SHA256 da parte del cliente.

Sarà possibile visualizzarlo nella richiesta SAML inviata da SAP Ariba. Ad esempio:

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

Per correggere questo problema, il team IT (Information Technology) del cliente deve attenersi alla seguente procedura:

1. Caricare il certificato Ariba per handshake o relazione di trust.
2. Aprire l'endpoint impostato per Ariba in ADFS.
3. Passare alla pagina Proprietà Ariba.
4. Fare clic sulla scheda Avanzate.
5. Impostare Specificare l'algoritmo hash sicuro da utilizzare per questa relazione di trust del componente su SHA1.
6. Fare clic sull'URL (Uniform Resource Locator) per controllare se l'autenticazione utente ha esito positivo.

L'utente non esiste. L'errore potrebbe anche essere visualizzato per molti altri motivi, ad esempio il certificato non corrispondente in entrambe le estremità, il formato NameId non corrispondente in entrambe le estremità, l'utente è inattivo nel sistema Ariba, l'account utente non esiste in Ariba e così via.

Assicurarsi che l'ID utente inviato dal cliente corrisponda a quanto memorizzato in Ariba come UserID. In questo caso viene fatta distinzione tra maiuscole e minuscole.

Acquisti
Contratti strategici
Servizi dell’applicazione di approvvigionamento > Framework applicazione > Single Sign-On
Strategic Sourcing
Supplier Information & Performance Management