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

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

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

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

在这两种模式下，我们可以确定 NameID 是否与 Ariba 中的 UserID 不同。

捕获和检索日志的步骤：

1. 打开权限 DEBUG, sso: DEBUG 和用户：所有 UI 节点的信息。
2. 在用户尝试通过单点登录 (SSO) 登录 Ariba 之后。关闭所有采购或寻源 UI 节点上的日志并检索日志文件。
3. 在所有 UI 节点日志中，搜索 (Ctrl+F) SAMLResponse 并从日志文件中复制整个 SAMLResponse 行（无论在何处找到）。请确保记下客户的社区节点和用户登录尝试的时间，以便您知道正在检索正确的 SAMLResponse。
4. 在 Notepad++ 上粘贴 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) 检查用户验证是否成功。

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

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

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