Asegúrese de que el certificado del servidor web sea correcto y, siempre que se realice una actualización del certificado, Ariba solicita a los clientes que actualicen el nuevo certificado en su servidor IdP para que el establecimiento de comunicación Hypertext Transfer Protocol Secure (HTTPS) esté completo y no esté bloqueado. El nuevo certificado actualizado por Ariba es del tipo SHA2 (algoritmo de control seguro 2, 256 bits). En este caso, el cliente ha actualizado el nuevo certificado en su servidor ADFS y también ha modificado el algoritmo de control seguro para utilizarlo para esta confianza de parte de confianza a SHA2.

En otro caso, el cliente no ha actualizado el nuevo certificado de firma de Ariba y aún tiene el certificado antiguo, que ha vencido.

Podemos capturar los registros de dos maneras.

1. Podemos habilitar el inicio de sesión avanzado en el dominio del cliente > SSO (seguimiento de inicio de sesión único) y autenticación (solicitudes de autenticación) y, después, solicitar al cliente que reproduzca el error.
2. Capturar logs mediante un complemento externo de Google Chrome > tracer SAML.

En ambos modos podemos identificar si el NameID es diferente del UserID en Ariba.

Pasos para capturar y recuperar logs:

1. Activar aut.: DEBUG, sso: DEBUG y el usuario: Info para todos los nodos de IU.
2. Después de que el usuario intente iniciar sesión en Ariba a través de Single Sign-On (SSO). Desactive los registros en todos los nodos de la IU de compras o sourcing y recupere los archivos de registro.
3. En todos los logs de nodos de IU, busque (Ctrl+F) SAMLResponse y copie toda la línea SAMLResponse del archivo de log (donde sea que se encuentre). Asegúrese de tomar nota del nodo de comunidad del cliente y la hora del intento de inicio de sesión del usuario, de modo que sepa que está recuperando la SAMLResponse correcta.
4. Pegue la SAMLResponse como se muestra a continuación en Notepad++, busque la etiqueta <NameID> y vea qué ID de usuario se transfiere en la respuesta SAML.

Además, también podemos ver los puntos de respuesta SAML al problema de firma.

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

El nuevo certificado actualizado en nuestros servidores web es del algoritmo SHA256 (algoritmo Secure Hash 2, 256 bits). Sin embargo, aún generamos firmas con SHA1 y no SHA256. (Tenga en cuenta que las autoridades de certificación no proporcionarán nuevos certificados SHA1, ya que la mayoría de los navegadores tratan los sitios con un certificado SHA1 como inseguro).

Si el SSO para el territorio está configurado para enviar solicitudes SAML, el cliente debe tener el nuevo certificado y no un certificado vencido de Ariba.

SAP Ariba admite los certificados SHA1 y SHA256 del cliente (proveedor de identidades) y no hace que el certificado SHA256 sea obligatorio por parte del cliente.

Podrá verlo en la solicitud SAML enviada desde SAP Ariba. Por ejemplo:

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

Para corregir este problema, el equipo de tecnología de la información (TI) del cliente debe seguir los siguientes pasos:

1. Cargue el certificado de Ariba para establecimiento de comunicación o confianza.
2. Abra el conjunto de extremos para Ariba en ADFS.
3. Vaya a la página Propiedades de Ariba.
4. Haga clic en la pestaña Avanzado.
5. Fije Especificar el algoritmo de control seguro que se utilizará para esta relación de confianza en SHA1.
6. Haga clic en el localizador de recursos uniforme (URL) para verificar si la autenticación del usuario es correcta.

El usuario no existe. El error también puede aparecer por muchos otros motivos, como que el certificado no coincida en ambos extremos, que el formato de NameId no coincida en ambos extremos, que el usuario esté inactivo en el sistema de Ariba, que la cuenta de usuario no exista en Ariba, etc.

Asegúrese de que el UserID enviado por el cliente coincida con lo que se almacena en Ariba como UserID. Esto distingue entre mayúsculas y minúsculas.

Compras
Contratos estratégicos
Gestión de la información y el rendimiento de los proveedores
Servicios de aplicación de compras > Marco de aplicación > Identificación única
Sourcing estratégico