确保 Web 服务器证书正确，并且每当执行证书更新时，Ariba 都会要求客户更新其 IdP 服务器上的新证书，以便超文本传输协议安全 (HTTPS) 握手完整且不会被阻止。Ariba 更新的新证书的类型为 SHA2（安全哈希算法 2，256 位）。在这种情况下，客户更新了其 ADFS 服务器上的新证书，还更改了安全哈希算法，以用于此依赖方对 SHA2 的信任。

在其他情况下，客户不会更新新的 Ariba 签名证书，但仍具有已过期的旧证书。

我们可以通过两种方式捕获日志。

1. 我们可以在客户端领域 > SSO（单点登录跟踪）和 Auth（验证请求）中启用高级日志记录，然后要求客户重现错误。
2. 使用外部 google chrome 插件 > SAML 跟踪器捕获日志。

在这两种模式下，我们可以识别名称标识是否与 Ariba 中的用户标识不同。

捕获和检索日志的步骤：

1. 打开权限：调试，sso：调试，用户：所有 UI 节点的信息。
2. 用户尝试通过单点登录 (SSO) 登录 Ariba 之后。关闭所有采购或寻源 UI 节点上的日志并检索日志文件。
3. 在所有 UI 节点日志中，搜索 (Ctrl+F) 以获取 SAMLResponse，并从日志文件中复制整个 SAMLResponse 行（无论在何处找到）。请务必记下客户的社区节点和用户登录尝试的时间，以便您知道您正在检索正确的 SAMLResponse。
4. 在记事本++ 上粘贴 SAMLResponse，然后搜索 <NameID> 标签并查看在 SAML 响应中传递的用户标识。

此外，我们还可以看到签名问题的 SAML 响应点。

</ds:Signature><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder"/><samlp:StatusMessage>无法验证签名</samlp:StatusMessage></samlp:Status></samlp:Response>

在 Web 服务器上更新的新证书属于 SHA256 算法（安全散列算法 2，256 位）。但是，我们仍然使用 SHA1 而不是 SHA256 生成签名。（请注意，证书颁发机构不会提供新的 SHA1 证书，因为大多数浏览器将具有 SHA1 证书的站点视为不安全。）

如果将领域的 SSO 配置为发送 SAML 请求，则客户需要具有新证书，而不是 Ariba 的过期证书。

SAP Ariba 同时支持来自客户（身份提供者）的 SHA1 和 SHA256 证书，并且不会将证书设置为客户方必需的 SHA256 证书。

您将能够在从 SAP Ariba 发送的 SAML 请求中看到。例如：

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

为了更正此问题，客户的信息技术 (IT) 团队需要执行以下步骤：

1. 上载 Ariba 证书以进行握手或信任。
2. 在 ADFS 中打开 Ariba 的端点集。
3. 转到 Ariba 属性页面。
4. 单击“高级”选项卡。
5. 设置指定用于此依赖方信任的安全哈希算法 SHA1。
6. 单击统一资源定位符 (URL) 以检查用户验证是否成功。

用户不存在。错误也可能由于许多其他原因出现，例如两端证书不匹配、两端的 NameId 格式不匹配、用户在 Ariba 系统中处于非活动状态、用户帐户在 Ariba 上不存在等。

确保从客户发送的用户标识符与 Ariba 中存储的用户标识符相匹配。这区分大小写。

Supplier Information & Performance Management
战略合同
战略寻源
采购
采购应用程序服务 > 应用程序框架 > 单点登录