워크벤치가 사용하는 JRE(Java Runtime Environment)는 선택하는 디지털 인증서가 요청하는 암호화 레벨을 지원해야 합니다. 예를 들어, 256비트 암호화가 필요한 디지털 인증서를 128비트 암호화만 지원하는 JRE와 함께 사용할 수 없습니다. 기본적으로, 워크벤치는 제한되거나 한계가 정해진 강도의 암호를 사용하여 구성됩니다. 제한 정도가 낮은 암호화 알고리즘을 사용하려면 무제한 관할 정책 파일(local_policy.jar 및 US_export_policy.jar)을 다운로드하고 적용해야 합니다.
http://www.ibm.com/developerworks/java/jdk/security/50/ 사이트에서 무제한 관할 정책 파일을 다운로드할 수 있습니다.
IBM SDK 정책 파일을 클릭하고 developerWorks®에 로그인하여 무제한 관할 정책 파일을 얻으십시오. 이러한 정책 파일을 설치하기 전에 원본 파일을 나중에 복원할 경우를 대비해 기존의 정책 파일을 백업하십시오. 그런 다음, 무제한 관할 정책 파일로 /jre/lib/security/ 디렉토리에 있는 파일을 겹쳐쓰십시오.
단순 인증(서버 인증): 이 경우 테스트 클라이언트가 서비스를 신뢰할 수 있는지 판별해야 합니다. 키 저장소를 설정할 필요가 없습니다. 항상 신뢰 옵션을 선택하면 서버 인증서 키 저장소를 제공할 필요가 없습니다.
서비스를 인증하려는 경우, 인증서 신뢰 저장소를 구성할 수 있고, 이는 신뢰된 서비스의 인증서를 포함합니다. 이 경우, 테스트는 유효한 인증서를 수신할 것으로 예상합니다.
이중 인증(클라이언트 및 서버 인증): 이 경우 서비스가 루트 권한에 따라 테스트 클라이언트를 인증해야 합니다. 인증된 클라이언트로 테스트를 인증하기 위해 생성해야 하는 클라이언트 인증서 키 저장소를 제공해야 합니다.
프록시를 통해 서비스 테스트를 레코딩할 때 레코딩 프록시는 서비스와 클라이언트 사이에 위치합니다. 이 경우, 클라이언트에 대한 실제 서비스(단순 인증의 경우) 및 서비스에 대한 클라이언트(이중 인증의 경우)로 자체 인증하기 위해 레코딩 프록시의 SSL 설정을 구성해야 합니다. 이는 레코딩 프록시에 적당한 인증서를 제공해야 한다는 것을 의미합니다.
스텁 서비스를 사용할 때 자체를 실제 서버로 인증하도록 스텁 서비스의 SSL 설정도 구성할 수 있습니다. 이는 서비스 스텁에 적당한 인증서를 제공해야 한다는 것을 의미합니다.
해당 제품은 Microsoft NT LAN 관리자(NTLMv1 및 NTLMv2) 및 Kerberos 인증을 지원합니다. 레코딩 단계 중에 테스트의 일부로 인증 정보가 레코딩됩니다.
NTLMv2 지원을 사용하려면 워크벤치에 써드파티 라이브러리를 추가해야 합니다. 자세한 정보는 NTLMv2 인증을 위한 워크벤치 구성의 내용을 참조하십시오.
SSL 및 SOAP 보안 프로토콜 모두에 대해 디지털 인증서를 사용하여 서비스를 테스트할 수 있습니다. 디지털 인증서는 작업공간에서 액세스 가능한 JKS(Java Key Store) 키 저장소 자원에 포함되어야 합니다. 키 저장소 파일을 사용할 때 보안 편집기 및 테스트 편집기 모두에서 키에 액세스하는 데 필요한 비밀번호를 설정해야 합니다. SOAP 보안의 경우, 키의 명시적 이름을 제공하고 키 저장소의 개인용 키에 액세스하는 데 필요한 비밀번호를 제공해야 합니다.
배열은 지원되지 않습니다.
스펙 부족으로 인해 JMS(Java Message Service) 전송에서는 첨부가 지원되지 않습니다. 엔벨로프는 UTF-8 인코딩을 사용하여 직접 전송됩니다.
모든 보안 알고리즘을 모든 JRE(Java Runtime Environment) 구현에서 항상 사용할 수 있는 것은 아닙니다. 특정 보안 구현을 사용할 수 없는 경우 이 제품이 사용하는 JRE의 클래스 경로에 필요한 라이브러리를 추가하십시오.
일반 서비스 테스터가 XML 문서에 반영된 엔벨로프를 표시합니다. 그러나, 보안 알고리즘은 엔벨로프를 2진으로 간주합니다. 따라서, 수신 및 발신 메시지가 올바르게 암호화되지만 테스트 내에서는 복호화된 채로 있도록 SOAP 보안 구성을 설정해야 합니다.
가상 사용자 성능은 컨테이너 애플리케이션의 구현에 따라 다릅니다. HTTP 전송의 경우, 제품은 Windows에서 최대 900명의 동시 가상 사용자로 테스트되고 Linux에서는 600명의 가상 사용자로 테스트됩니다. JMS의 경우, 이 숫자가 JMS의 비동기 구현에 따라 다를 수 있지만 최대 동시 가상 사용자는 100명입니다. 이러한 값을 초과하면 연결 오류가 발생하고 트랜잭션 비율이 감소합니다.