Asegúrese de que el certificado del servidor web sea correcto y, cada vez 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 de Hypertext Transfer Protocol Secure (HTTPS) se complete y no esté bloqueado. El nuevo certificado que Ariba ha actualizado es del tipo SHA2 (Secure Hash Algorithm 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 relación de confianza con 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 logs de dos maneras.

1. Podemos activar 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 pedir al cliente que reproduzca el error.
2. Capture logs utilizando 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. Active Autorización: DEBUG, sso: DEBUG y el usuario: Información para todos los nodos de IU.
2. Después de que el usuario intente iniciar sesión en Ariba mediante la identificación única (SSO). Desactive los logs en todos los nodos de IU de aprovisionamiento o sourcing y recupere los archivos de log.
3. En todos los logs de nodos de IU, busque (Ctrl+F) SAMLResponse y copie toda la línea SAMLResponse del fichero de log (donde se encuentre). Asegúrese de tomar nota del nodo de la 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 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 (Secure Hash Algorithm 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 a los sitios con un certificado SHA1 como inseguros).

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 sea obligatorio un certificado SHA256 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 puntos finales para Ariba en ADFS.
3. Vaya a la página Propiedades de Ariba.
4. Haga clic en la pestaña Avanzadas.
5. Fije Especificar el algoritmo de control seguro que se debe utilizar para esta relación de confianza con SHA1.
6. Haga clic en Localizador uniforme de recursos (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 el certificado no coincide en ambos extremos, el formato NameId no coincide en ambos extremos, el usuario está inactivo en el sistema Ariba, la cuenta de usuario no existe en Ariba, etc.

Asegúrese de que el UserID enviado desde el cliente coincida con lo almacenado 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