Ogólny klient usług - przegląd

Ogólny klient usług służy do wysyłania żądań do usług używających transportu HTTP, JMS, WebSphere MQ lub Microsoft .NET. Ogólny klient usług umożliwia również wyświetlenie odpowiedzi zwróconej przez usługę.

Ogólny klient usług jest przydatny do debugowania lub testowania usługi, w przypadku gdy nie ma dostępu do dedykowanego klienta przeznaczonego do wysłania żądania. Można konfigurować wiele różnych konfiguracji transportu i zabezpieczeń dla usługi, edytować parametry żądania oraz wysyłać załączniki.

Po pomyślnym wywołaniu żądania zwrócone dane jego komunikatu są dodawane do listy Historia żądań. Tej funkcji można użyć w celu przejrzenia wyników zwróconych wcześniej.

Jeśli jest używany produkt IBM® Rational Performance Tester lub IBM Rational Service Tester for SOA Quality, można wybrać żądania w polu Historia żądań i kliknąć opcję Generate Test (Generuj test), aby wygenerować test powielający wszystkie wybrane żądania. Test można edytować w celu zastąpienia zarejestrowanych wartości testowych zmiennymi danymi testowymi lub dodania do testu korelacji danych dynamicznych. Można także ustawić punkty weryfikacji w zawartości dokumentów XML w odpowiedzi usługi.

Obsługiwane usługi

Ogólny klient usług umożliwia wysyłanie żądań dla wielu typów usług korzystających z następujących protokołów transportowych:
  • HTTP
  • Java™ Message Service (JMS), w tym implementacje JBoss i WebSphere
  • WebSphere MQ
  • Microsoft .NET Framework Windows Communication Foundation (WCF)
Uwaga: Jeśli jest używany produkt IBM Security AppScan, obsługiwany jest tylko protokół transportowy HTTP.

Szyfrowanie i zabezpieczenia

Środowisko Java Runtime Environment (JRE) używane przez środowisko robocze musi obsługiwać poziom szyfrowania wymagany przez wybrany certyfikat cyfrowy. Na przykład nie można używać certyfikatu cyfrowego wymagającego szyfrowania 256-bitowego ze środowiskiem JRE, które obsługuje tylko szyfrowanie 128-bitowe. W środowisku roboczym są domyślnie skonfigurowane szyfry z nałożonymi ograniczeniami lub ograniczoną mocą. Aby użyć mniej ograniczonych algorytmów szyfrowania, należy pobrać i zastosować pliki strategii o nieograniczonej jurysdykcji (local_policy.jar i US_export_policy.jar).

Pliki strategii o nieograniczonej jurysdykcji można pobrać z następującego serwisu: http://www.ibm.com/developerworks/java/jdk/security/50/

Aby uzyskać pliki strategii o nieograniczonej jurysdykcji, należy kliknąć opcję Pliki strategii pakietu SDK IBM, a następnie zalogować się do serwisu developerWorks. Przed zainstalowaniem tych plików strategii należy utworzyć kopię zapasową istniejących plików strategii na wypadek, gdyby było konieczne późniejsze odtworzenie oryginalnych plików. Następnie należy nadpisać pliki w katalogu /jre/lib/security/ przy użyciu plików strategii o nieograniczonej jurysdykcji.

Uwierzytelnianie SSL

Testy usług obsługują mechanizmy prostego lub podwójnego uwierzytelniania SSL.
  • Uwierzytelnianie proste (uwierzytelnianie serwera): w tym przypadku klient testowy wymaga określenia, czy usługa jest zaufana. Nie ma potrzeby konfigurowania magazynu kluczy. Jeśli zostanie wybrana opcja Zawsze ufaj, nie ma potrzeby udostępniania magazynu kluczy certyfikatów serwera.

    Aby przeprowadzić rzeczywiste uwierzytelnienie usługi, można skonfigurować magazyn zaufanych certyfikatów, który zawiera certyfikaty zaufanych usług. W tym przypadku test będzie oczekiwał otrzymania poprawnego certyfikatu.

  • Uwierzytelnianie podwójne (uwierzytelnianie klienta i serwera): w tym przypadku usługa wymaga uwierzytelnienia klienta testowego zgodnie z uprawnieniem administratora. Należy udostępnić magazyn kluczy certyfikatów klienta, którego utworzenie jest konieczne w celu uwierzytelnienia testu jako przeprowadzanego przez certyfikowany klient.

Jeśli test usługi jest rejestrowany za pośrednictwem proxy, proxy rejestrowania znajduje się między usługą i klientem. W tym przypadku należy skonfigurować ustawienia protokołu SSL dla proxy rejestrowania tak, aby uwierzytelniało się w kliencie jako rzeczywista usługa (dla uwierzytelniania prostego) i jako klient w usłudze (dla uwierzytelniania podwójnego). Oznacza to, że proxy rejestrowania musi mieć dostęp do odpowiednich certyfikatów.

W przypadku korzystania z kodów pośredniczących usług można również skonfigurować ustawienia protokołu SSL kodu pośredniczącego usługi tak, aby uwierzytelniał się jako rzeczywisty serwer. Oznacza to, że kod pośredniczący usługi musi mieć dostęp do odpowiedniego certyfikatu.

Uwierzytelnianie NTLM i Kerberos

Produkt obsługuje uwierzytelnianie Microsoft NT LAN Manager (NTLMv1 i NTLMv2) oraz protokół Kerberos. Informacje o uwierzytelnianiu są rejestrowane jako część testu podczas fazy rejestrowania.

Aby włączyć obsługę protokołu NTLMv2, należy dodać do środowiska roboczego bibliotekę innej firmy. Więcej informacji na ten temat zawiera sekcja Konfigurowanie środowiska roboczego na potrzeby uwierzytelniania NTLM w wersji 2.

Certyfikaty cyfrowe

Usługi z certyfikatami cyfrowymi można testować zarówno w przypadku protokołu SSL, jak i protokołu zabezpieczeń SOAP. Certyfikaty cyfrowe muszą znajdować się w zasobach magazynu kluczy Java Key Store (JKS), które są dostępne w obszarze roboczym. Podczas operacji na plikach kluczy należy zarówno w edytorze zabezpieczeń, jak i w edytorze testów ustawić hasło wymagane do uzyskania dostępu do kluczy. W przypadku zabezpieczeń protokołu SOAP może być konieczne udostępnienie jawnej nazwy klucza oraz hasła wymaganego do uzyskania dostępu do kluczy prywatnych w magazynie kluczy.

Ograniczenia

Tablice nie są obsługiwane.

Z powodu braku specyfikacji załączniki nie są obsługiwane w przypadku transportu Java Message Service (JMS). Koperta jest wysyłana bezpośrednio z użyciem kodowania UTF-8.

Wszystkie algorytmy zabezpieczeń nie są zawsze dostępne w każdej implementacji środowiska Java Runtime Environment (JRE). Jeśli określona implementacja zabezpieczeń jest niedostępna, należy dodać wymagane biblioteki do ścieżki klas środowiska JRE, z którego korzysta produkt.

Klient Generic Service Tester wyświetla kopertę w sposób, w jaki jest przedstawiona w dokumencie XML. Jednak algorytmy zabezpieczeń traktują kopertę jako dane binarne. Z tego powodu należy skonfigurować zabezpieczenia SOAP tak, aby przychodzące i wychodzące komunikaty były poprawnie szyfrowane, ale pozostały zdeszyfrowane w czasie testu.

Protokół transportowy Microsoft .NET nie obsługuje transakcji, zasięgów ani żądań w trybie dupleks, takich jak wywołania zwrotne lub dwukierunkowe usługi oparte na transporcie MS-MQ.


Opinia