JRE (Java Runtime Environment) che il workbench utilizza deve supportare il livello di crittografia richiesto dal certificato digitale selezionato. Ad esempio, non è possibile utilizzare un certificato digitale che richiede la crittografia a 256 bit con un JRE che supporta solo la crittografia a 128 bit. Per impostazione predefinita, il workbench viene configurato con una codifica di lunghezza limitata o vincolata. Per utilizzare algoritmi meno vincolati, è necessario scaricare e applicare file di politiche di giurisdizione limitata (local_policy.jar e US_export_policy.jar).
È possibile scaricare file di giurisdizione non limitata da questo sito: http://www.ibm.com/developerworks/java/jdk/security/50/
Fare clic su IBM SDK Policy files e accedere a developerWorks per ottenere i file di giurisdizione illimitata. Prima di installare questi file delle politiche, eseguire il backup dei file delle politiche esistenti nel caso in cui successivamente si desidera ripristinare i file originali. Sovrascrivere, quindi, i file nella directory /jre/lib/security/ con file delle politiche di giurisdizione illimitata.
L'autenticazione semplice (autenticazione server): In questo caso, il client del test deve determinare se il servizio è attendibile. Non è necessario configurare un keystore. Se viene selezionata l'opzione Considera sempre attendibile, non è necessario fornire un keystore del certificato del server.
Se si desidera veramente autenticare il servizio, è possibile configurare un truststore del certificato che contiene i certificati dei servizi attendibili. In questo caso, il test presuppone di ricevere un certificato valido.
Autenticazione doppia (autenticazione client e server): In questo caso, il servizio deve autenticare il client del test in base all'autorità root. È necessario fornire il keystore del certificato client che deve essere prodotto per autenticare il test come un client certificato.
Quando si registra un test del servizio tramite un proxy, il proxy di registrazione si trova tra il servizio ed il client. In questo caso, è necessario configurare le impostazioni SSL del proxy di registrazione per l'autenticazione come servizio effettivo al client (per l'autenticazione semplice), e come client al servizio (per l'autenticazione doppia). Questo significa che è necessario fornire il proxy di registrazione con i certificati adeguati.
Quando si utilizzano i servizi dello stub, è inoltre possibile configurare le impostazioni SSL del servizio stub per l'autenticazione come server effettivo. Questo significa che è necessario fornire lo stub di registrazione con il certificato adeguato.
Il prodotto supporta l'autenticazione Microsoft NT LAN Manager (NTLMv1, NTLMv2) e Kerberos. Le informazioni di autenticazione sono registrate come parte del test durante la fase di registrazione.
Per abilitare il supporto NTLMv2, è necessario aggiungere una libreria di terza parte al workbench. Per ulteriori informazioni, vedere Configurazione del workbench per l'autenticazione NTLMv2.
È possibile eseguire il test sui servizi con i certificati digitali per entrambi i protocolli di sicurezza SSL e SOAP. I certificati digitali devono essere contenuti nelle risorse del keystore JKS (Java Key Store) accessibili nello spazio di lavoro. Quando si utilizzano i file del keystore, è necessario impostare la password richiesta per accedere alle chiavi in entrambi gli editor di sicurezza e di test. Per la sicurezza SOAP potrebbe essere necessario fornire un nome esplicito per la chiave e fornire una password per accedere alle chiavi private nel keystore.
Gli array non sono supportati.
A causa di una mancanza di specifiche, gli allegati non sono supportati con il trasporto JMS(Java Message Service). L'envelope viene inviato direttamente mediante la codifica UTF-8.
Tutti gli algoritmi di sicurezza non sono sempre disponibili per ogni implementazione JRE (Java Runtime Environment). Se una determinata implementazione di sicurezza non è disponibile, aggiungere le librerie richieste al percorso della classe di JRE utilizzata dal prodotto.
Il tester di servizio generico visualizza l'envelope come riportato nel documento XML. Tuttavia, gli algoritmi di sicurezza considerano l'envelope come binario. Quindi, è necessario impostare la configurazione della sicurezza SOAP in modo tale che i messaggi in entrata e in uscita siano crittografati correttamente ma restino decrittografati nel test.
Le prestazioni dell'utente virtuale dipendono dall'implementazione dell'applicazione del contenitore. Per un trasporto HTTP, sul prodotto è stato eseguito il test con un massimo di 900 utenti virtuali simultanei in Windows e 600 in Linux. Per JMS, il massimo è di 100 utenti virtuali simultanei, sebbene tale numero può variare a causa dell'implementazione asincrona di JMS. Al di là di tali valori, è possibile che si verifichino errori di connessione e la velocità di transazione diminuirà.