Die Java Runtime Environment (JRE), die von der Workbench verwendet wird, muss die Verschlüsselungsebene unterstützen, die von dem ausgewählten digitalen Zertifikat unterstützt wird. So können Sie beispielsweise kein digitales Zertifikat, das eine 256-Bit-Verschlüsselung erfordert, für eine JRE verwenden, die nur eine 128-Bit-Verschlüsselung unterstützt. Standardmäßig ist die Workbench mit eingeschränkter oder begrenzter Verschlüsselung konfiguriert. Zur Verwendung weniger eingeschränkter Verschlüsselungsalgorithmen müssen Sie die Dateien für uneingeschränkte Standortrichtlinien (local_policy.jar und US_export_policy.jar) herunterladen und anwenden.
Sie können uneingeschränkte Standortrichtliniendateien von der folgenden Site herunterladen: http://www.ibm.com/developerworks/java/jdk/security/50/
Klicken Sie auf IBM SDK Policy files, und melden Sie sich dann bei developerWorks an, um die uneingeschränkten Standortrichtliniendateien zu erhalten. Es wird empfohlen, vor dem Installieren dieser Richtliniendateien die vorhandenen Richtliniendateien zu sichern, falls Sie diese zu einem späteren Zeitpunkt wiederherstellen möchten. Überschreiben Sie anschließend die Dateien im Verzeichnis /jre/lib/security/ mit den uneingeschränkten Standortrichtliniendateien.
Einfache Authentifizierung (Serverauthentifizierung): In diesem Fall muss der Testclient bestimmen, ob der Test vertrauenswürdig ist. Das Einrichten eines Keystores ist nicht notwendig. Wenn Sie die Option Immer vertrauen auswählen, müssen Sie keinen serverspezifischen Zertifikatskeystore einrichten.
Wenn Sie den Service wirklich authentifizieren wollen, können Sie einen Zertifikatstruststore konfigurieren, der die Zertifikate vertrauenswürdiger Services enthält. In diesem Fall erwartet der Test den Eingang eines gültigen Zertifikats.
Doppelte Authentifizierung (Client- und Serverauthentifizierung): In diesem Fall muss der Service den Testclient gemäß seiner Rootberechtigung authentifizieren. Sie müssen den clientspezifischen Zertifikatskeystore angeben, der erstellt werden muss, um den Test als zertifizierten Client zu authentifizieren.
Beim Aufzeichnen eines Servicetests über einen Proxy befindet sich der Recorder-Proxy zwischen dem Service und dem Client. In diesem Fall müssen Sie die SSL-Einstellungen des Recorder-Proxy konfigurieren, um diesen als den tatsächlichen Service für den Client (für die einfache Authentifizierung) und den Client für den Service (für doppelte Authentifizierung) zu authentifizieren. Das bedeutet, dass Sie den Recorder-Proxy mit den entsprechenden Zertifikaten angeben müssen.
Bei Verwendung von Stub-Services können Sie auch die SSL-Einstellungen des Stub-Service konfigurieren, damit dieser sich als tatsächlicher Server authentifizieren kann. Das bedeutet, dass Sie den Service-Stub mit dem entsprechenden Zertifikat angeben müssen.
Das Produkt unterstützt Microsoft NT LAN Manager (NTLMv1 und NTLMv2) sowie Kerberos-Authentifizierung. Die Authentifizierungsinformationen werden als Teil des Tests während der Aufzeichnungsphase aufgezeichnet.
Zur Aktivierung der NTLMv2-Unterstützung müssen Sie eine Bibliothek eines anderen Anbieters zur Workbench hinzufügen. Weitere Informationen siehe Umgebung für NTLMv2-Authentifizierung konfigurieren.
Sie können Services mit digitalen Zertifikaten für die Sicherheitsprotokolle SSL und SOAP testen. Digitale Zertifikate müssen in Java-Keystoreressourcen (JKS) enthalten sein, die über den Arbeitsbereich zugänglich sind. Bei der Arbeit mit Keystoredateien müssen Sie das für den Zugriff auf die Schlüssel erforderliche Kennwort sowohl im Sicherheitseditor als auch im Testeditor festlegen. Bei der SOAP-Sicherheit kann es notwendig sein, einen expliziten Namen für den Schlüssel sowie ein Kennwort für den Zugriff auf die privaten Schlüssel im Keystore anzugeben.
Matrizen werden nicht unterstützt.
Da keine entsprechende Spezifikation vorhanden ist, werden Anhänge beim Java Message Service-Transport (JMS) nicht unterstützt. Die Rahmenanweisung wird direkt mit UTF-8-Codierung gesendet.
Es stehen nicht immer alle Sicherheitsalgorithmen für alle Java Runtime Environment-Implementierungen (JRE) zur Verfügung. Wenn eine bestimmte Sicherheitsimplementierung nicht verfügbar ist, fügen Sie die erforderlichen Bibliotheken zum Klassenpfad der JRE hinzu, die vom Produkt verwendet wird.
Im generischen Service Tester wird die Rahmenanweisung wie im XML-Dokument angezeigt. Sicherheitsalgorithmen gehen jedoch von einer binären Rahmenanweisung aus. Sie müssen die SOAP-Sicherheitskonfiguration daher so konfigurieren, dass die eingehenden und ausgehenden Aufrufe ordnungsgemäß verschlüsselt werden und im Test immer entschlüsselt bleiben.
Die Leistung für virtuelle Benutzer hängt von der Implementierung der Containeranwendung ab. Für den HTTP-Transport wurde das Programm mit maximal 900 gleichzeitigen virtuellen Benutzern unter Windows bzw. 600 virtuellen Benutzern unter Linux getestet. Bei JMS liegt das Maximum bei 100 gleichzeitigen virtuellen Benutzern. Dieser Wert kann jedoch aufgrund der asynchronen Implementierung von JMS schwanken. Bei größeren Werten als den genannten können Verbindungsfehler auftreten, und die Transaktionsrate nimmt ab.