| |||||||||
웹 서버 인증서가 올바른지 확인하고, 인증서 갱신이 수행될 때마다 Ariba에서 고객에게 IdP 서버의 새 인증서를 업데이트하도록 요청하여 하이퍼텍스트 전송 프로토콜 보안(HTTPS) 핸드셰이크가 완료되고 차단되지 않도록 합니다. 갱신된 새 인증서는 SHA2(Secure Hash Algorithm 2, 256비트) 유형입니다. 이 경우 고객은 ADFS 서버의 새 인증서를 업데이트하고 이 신뢰 당사자 트러스트에서 SHA2로 사용할 보안 해시 알고리즘을 변경했습니다.
다른 경우에는 고객이 새 Ariba 서명 인증서를 갱신하지 않았으며 만료되는 기존 인증서를 가지고 있습니다.
두 가지 방법으로 로그를 캡처할 수 있습니다.
두 모드 모두에서 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>
웹 서버에서 업데이트된 새 인증서는 SHA256 알고리즘(보안 해시 알고리즘 2, 256비트)입니다. 그러나 SHA256이 아닌 SHA1을 사용하여 서명을 생성합니다. (대부분의 브라우저에서는 SHA1 인증서가 안전하지 않은 사이트를 처리하기 때문에 인증 기관에서 새로운 SHA1 인증서를 제공하지 않습니다.)
영역에 대한 SSO가 SAML 요청을 전송하도록 구성된 경우, 고객은 Ariba의 만료된 인증서가 아닌 새 인증서를 보유해야 합니다.
SAP Ariba는 고객(ID 프로바이더)의 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 가 Ariba에 사용자 ID 로 저장된 것과 일치하는지 확인합니다. 대소문자를 구분합니다.
공급자 정보 및 실적 관리
구매
구매 응용프로그램 서비스 > 응용프로그램 프레임워크 > SSO(Single Sign-On)
전략적 계약
전략적 소싱