Prostředí JRE (Java Runtime Environment) používané pracovní plochou musí podporovat úroveň šifrování vyžadovanou vámi vybraným digitálním certifikátem. Nelze například použít digitální certifikát, který vyžaduje 256bitové šifrování s prostředím JRE podporujícím pouze 128bitové šifrování. Standardně má pracovní plocha nakonfigurovány šifry s omezenou odolností. Chcete-li použít méně omezené šifrovací algoritmy, musíte si stáhnout a použít soubory zásad s neomezenou jurisdikcí (local_policy.jar a US_export_policy.jar).
Soubory zásad s neomezenou jurisdikcí si můžete stáhnout z těchto stránek: http://www.ibm.com/developerworks/java/jdk/security/50/
Klepněte na položku Soubory zásad IBM SDK a potom se přihlaste do developerWorks, kde získáte soubory zásad s neomezenou jurisdikcí. Před instalací těchto souborů zásad vytvořte zálohu stávajících souborů zásad pro případ, že byste se později chtěli k původním souborům vrátit. Potom tyto soubory v adresáři /jre/lib/security/ přepište soubory zásad s neomezenou jurisdikcí.
Jednoduché ověřování (ověřování serverem): V tomto případě potřebuje testovací klient určit, zda je služba důvěryhodná. Není třeba zřizovat úložiště klíčů. Pokud vyberete volbu Vždy důvěřovat, není nutné poskytovat úložiště klíčů pro certifikáty serveru.
Pokud chcete službu opravdu ověřit, je možné nakonfigurovat úložiště údajů o důvěryhodnosti certifikátů, které bude obsahovat certifikáty důvěryhodné služby. V tom případě bude test očekávat, že obdrží platný certifikát.
Dvojité ověřování (ověřování klientem a serverem): V tomto případě potřebuje služba ověřit testovacího klienta v souladu s oprávněním uživatele root. Je třeba zajistit úložiště klíčů pro certifikáty klienta, které musí být vytvořeny pro ověření testu jako certifikovaného klienta.
Při záznamu testu služby prostřednictvím serveru proxy se mezi službou a klientem nachází server proxy provádějící záznam. V tom případě je třeba nakonfigurovat nastavení SSL serveru proxy provádějícího záznam, aby se klientu prokazoval jako skutečná služba (v případě jednoduchého ověřování) a službě jako klient (v případě dvojitého ověřování). To znamená, že musíte zaznamenávajícímu serveru proxy zajistit odpovídající certifikáty.
Při použití služeb stubu je také možné nakonfigurovat nastavení SSL služby stubu, aby se prokazovala jako skutečný server. To znamená, že musíte stubu služby zajistit odpovídající certifikát.
Produkt podporuje ověření pomocí správce Microsoft NT LAN Manager (NTLMv1 a NTLMv2) a ověření Kerberos. Informace o ověření se ve fázi záznamu zaznamenávají jako součást testu.
Chcete-li povolit podporu NTLMv2, je třeba přidat na pracovní plochu knihovnu jiného dodavatele. Další informace viz Konfigurace pracovní plochy pro ověření NTLMv2.
Služby je možné testovat s digitálními certifikáty pro protokol zabezpečení SSL i SOAP. Digitální certifikáty se musí nacházet v prostředcích úložiště klíčů JKS (Java Key Store), které jsou přístupné v pracovním prostoru. Při práci se soubory úložiště klíčů je třeba nastavit heslo nezbytné pro přístup ke klíčům jak v editoru zabezpečení, tak v editoru testů. V případě zabezpečení SOAP bude možná nutné uvést explicitní název klíče a poskytnout heslo pro přístup k soukromým klíčům v úložišti klíčů.
Pole nejsou podporována.
Kvůli chybějícím specifikacím nejsou s přenosem Java Message Service (JMS) podporovány přílohy. Obálka je odeslána přímo pomocí kódování UTF-8.
Všechny algoritmy zabezpečení nejsou vždy dostupné pro každou implementaci Java Runtime Environment (JRE). Pokud není konkrétní implementace zabezpečení dostupná, přidejte nezbytné knihovny k cestě ke třídě JRE, kterou tento produkt používá.
Generický tester služeb zobrazuje obálku tak, jak se projevuje v dokumentu XML. Algoritmus zabezpečení nicméně považuje obálku za binární. Proto musíte vytvořit algoritmus zabezpečení SOAP tak, aby byly příchozí a odchozí zprávy správně zašifrovány, ale zůstaly uvnitř textu dešifrovány.
Výkon virtuálního uživatele závisí na implementaci aplikace kontejneru. V případě přenosu HTTP je produkt otestován s nejvýše 900 souběžnými virtuálními uživateli v systému Windows a 600 v systému Linux. V případě JMS je maximum 100 souběžných virtuálních uživatelů, ačkoli kvůli asynchronní implementaci JMS se toto číslo může lišit. Pokud jsou tyto hodnoty překročeny, klesá počet transakcí a může docházet k chybám připojení.