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 server IdP in modo che l'handshake HTTPS (Hypertext Transfer Protocol Secure) sia completo e non bloccato. Il nuovo certificato Ariba aggiornato è di tipo SHA2 (algoritmo Secure Hash 2, 256 bit). In questo caso, il cliente ha aggiornato il nuovo certificato sul proprio server ADFS e ha anche modificato l'algoritmo 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, che è scaduto.

Possiamo catturare i log in due modi.

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

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

Fasi 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 di tutti i nodi dell'interfaccia utente di approvvigionamento o di sourcing 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 venga trovata). 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 tag <NameID> e vedere quale ID utente viene trasmesso nella risposta SAML.

Inoltre, possiamo anche visualizzare i punti di risposta SAML al problema di 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 web server è dell'algoritmo SHA256 (Secure Hash Algorithm 2, 256 bits). Tuttavia, generiamo ancora firme con SHA1 e non SHA256. (Si noti che le autorità di certificazione non forniranno nuovi certificati SHA1, poiché la maggior parte dei browser considera i siti con un certificato SHA1 come insicuri.)

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 sia i certificati SHA1 che 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. 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 Trust.
2. Aprire l'insieme di endpoint per Ariba in ADFS.
3. Passare alla pagina Proprietà Ariba.
4. Fare clic sulla scheda Avanzate.
5. Impostare Specifica l'algoritmo hash sicuro da utilizzare per questa relazione del componente su SHA1.
6. Fare clic sull'URL (Uniform Resource Locator) per controllare se l'autenticazione dell'utente è stata eseguita correttamente.

L'utente non esiste. L'errore potrebbe anche essere visualizzato per molti altri motivi, ad esempio il certificato non corrispondente alle due estremità, il formato NameId non corrispondente a entrambi gli estremi, l'inattività dell'utente nel sistema Ariba, l'inesistenza dell'account utente in Ariba e così via.

Assicurarsi che l'ID utente inviato dal cliente corrisponda a quanto archiviato in Ariba come ID utente. 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