| |||||||||
Web サーバー証明書が正しいことを確認します。また、証明書の更新が実行されるたびに、Hypertext Transfer Protocol Secure (HTTPS) ハンドシェイクが完了してブロックされないように、Ariba はお客様に IdP サーバーで新しい証明書を更新するよう求めます。Ariba が更新した新しい証明書のタイプは SHA2 (セキュアハッシュアルゴリズム 2、256 ビット) です。この場合、お客様は ADFS サーバーで新しい証明書を更新し、また、SHA2 へのこの証明書利用者信頼に使用するようにセキュアハッシュアルゴリズムも変更しました。
別のケースでは、顧客が新しい Ariba 署名証明書を更新しておらず、有効期限が切れている古い証明書がまだあります。
ログを取得する方法は 2 つあります。
どちらのモードでも、NameID が Ariba のユーザー ID と異なるかどうかを識別することができます。
ログを取得および取得するステップ:
さらに、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 ビット) です。ただし、SHA256 ではなく SHA1 で署名が生成されます。(ブラウザの大部分では 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) チームが以下のステップに従う必要があります。
ユーザーが存在しません。証明書が両端で一致しない、NameId 形式が両端に一致しない、ユーザーが Ariba システムで無効である、ユーザーアカウントが Ariba に存在しないなど、その他の多くの理由でもエラーが表示される場合があります。
顧客から送信されたユーザー ID が、ユーザー ID として Ariba に保存されているユーザー ID と一致していることを確認します。これは大文字と小文字が区別されます。
Strategic Sourcing
Supplier Information & Performance Management
戦略的契約
購入
購買アプリケーションサービス > アプリケーションフレームワーク > シングルサインオン