Stellen Sie sicher, dass das Webserverzertifikat korrekt ist. Wenn eine Zertifikatsaktualisierung durchgeführt wird, fordert Ariba Kunden auf, das neue Zertifikat auf ihrem IdP-Server zu aktualisieren, damit der Hypertext Transfer Protocol Secure (HTTPS)-Handshake abgeschlossen und nicht blockiert wird. Das neue aktualisierte Zertifikat Ariba hat den Typ SHA2 (Secure Hash Algorithm 2, 256 bits). In diesem Fall hat der Kunde das neue Zertifikat auf seinem ADFS-Server aktualisiert und auch den sicheren Hash-Algorithmus so geändert, dass er für diese Vertrauensbeziehung zu SHA2 verwendet wird.

In einem anderen Fall hat der Kunde das neue Ariba-Signaturzertifikat nicht aktualisiert und hat weiterhin das alte Zertifikat, das abgelaufen ist.

Wir können die Protokolle auf zwei Arten erfassen.

1. Wir können die erweiterte Protokollierung im Client-Bereich > SSO (Single Sign-On Tracing) und Auth (Authentifizierungsanforderungen) aktivieren und anschließend den Kunden bitten, den Fehler zu reproduzieren.
2. Erfassen Sie Protokolle mit einem externen Google-Chrome-Plugin > SAML-Tracer.

In beiden Modi können wir ermitteln, ob sich die NameID von der Benutzer-ID in Ariba unterscheidet.

Schritte zum Erfassen und Abrufen von Protokollen:

1. Aktivieren Sie Auth: DEBUG, sso: DEBUG und den Benutzer: Info für alle UI-Knoten.
2. Nachdem der Benutzer versucht hat, sich über Single Sign-On (SSO) bei Ariba anzumelden. Deaktivieren Sie die Protokolle auf allen UI-Knoten der Beschaffung oder Bezugsquellenfindung, und rufen Sie die Protokolldateien ab.
3. Suchen Sie in allen UI-Knotenprotokollen (Strg+F) nach SAMLResponse, und kopieren Sie die gesamte SAMLResponse-Zeile aus der Protokolldatei (wo immer sie sich befindet). Notieren Sie sich den Community-Knoten des Kunden und die Zeit des Anmeldeversuchs des Benutzers, damit Sie wissen, dass Sie die richtige SAMLResponse abrufen.
4. Fügen Sie die SAMLResponse wie unten in Notepad++ beschrieben ein, suchen Sie nach dem Tag <NameID>, und prüfen Sie, welche Benutzer-ID in der SAML-Antwort übergeben wird.

Darüber hinaus werden auch SAML-Antwortpunkte auf Signaturproblem angezeigt.

</ds:Signature><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder"/><samlp:StatusMessage>Signatur kann nicht verifiziert werden</samlp:StatusMessage></samlp:Status></samlp:Response>

Das neue Zertifikat, das auf unseren Webservern aktualisiert wurde, entspricht dem SHA256-Algorithmus (Secure Hash Algorithm 2, 256 Bit). Wir generieren jedoch weiterhin Signaturen mit SHA1 und nicht SHA256. (Beachten Sie, dass Zertifizierungsstellen keine neuen SHA1-Zertifikate bereitstellen, da die meisten Browser Sites mit einem SHA1-Zertifikat als unsicher behandeln.)

Wenn SSO für den Bereich so konfiguriert ist, dass SAML-Anforderungen gesendet werden, muss der Kunde über das neue Zertifikat und nicht über ein abgelaufenes Zertifikat von Ariba verfügen.

SAP Ariba unterstützt sowohl SHA1- als auch SHA256-Zertifikate vom Kunden (Identity-Provider) und macht ein SHA256-Zertifikat auf Kundenseite nicht obligatorisch.

Sie können dies in der von SAP Ariba gesendeten SAML-Anforderung sehen. Beispiel:

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

Um dieses Problem zu beheben, muss das IT-Team des Kunden die folgenden Schritte ausführen:

1. Laden Sie das Ariba-Zertifikat für Handshake oder Trust hoch.
2. Öffnen Sie den Endpunkt, der für Ariba in ADFS festgelegt wurde.
3. Wechseln Sie zur Seite Ariba-Eigenschaften.
4. Klicken Sie auf die Registerkarte Erweitert.
5. Setzen Sie Geben Sie den sicheren Hash-Algorithmus an, der für diese Relying-Party-Vertrauensbeziehung zu SHA1 verwendet werden soll.
6. Klicken Sie auf Uniform Resource Locator (URL), um zu prüfen, ob die Benutzerauthentifizierung erfolgreich ist.

Der Benutzer ist nicht vorhanden. Der Fehler kann auch aus vielen anderen Gründen auftreten, z.B. wenn das Zertifikat auf beiden Enden nicht übereinstimmt, das NameId-Format auf beiden Enden nicht übereinstimmt, der Benutzer im Ariba-System inaktiv ist, das Benutzerkonto in Ariba nicht vorhanden ist usw.

Stellen Sie sicher, dass die vom Kunden gesendete Benutzer-ID mit der Benutzer-ID übereinstimmt, die in Ariba gespeichert ist. Dabei wird zwischen Groß- und Kleinschreibung unterschieden.

Einkauf
Procurement-Anwendungsservices > Anwendungsframework > Single Sign-On
Strategische Beschaffung
Strategische Verträge
Supplier Information and Performance Management