Języki definiowania polityki bezpieczeństwa. Prototypowa implementacja środowiska realizacji polityki bezpieczeństwa dla języka ORCA

Transkrypt

1 Program Operacyjny Innowacyjna Gospodarka: Dział anie Projekt: Nowe technologie informacyjne dla elektronicznej gospodarki i społeczeństwa informacyjnego oparte na paradygmacie SOA Raport częściowy z prac wykonanych w ramach zadania OB7 5 Języki definiowania polityki bezpieczeństwa dla SOA Prototypowa implementacja środowiska realizacji polityki bezpieczeństwa dla języka ORCA Bartosz Brodecki, Marek Chodorowski, Katarzyna Kozłowska, Michał Rzepka, Piotr Sasak, Michał Szychowiak Sieć Naukowa Technologii Informacyjnych SOA

2 Spis treści Streszczenie Wstęp...6 Cel i zakres raportu...7 Struktura raportu Model środowiska, przykładowe polityki i metody weryfikacji (aplikacje eksperymentalne) Architektura prototypowego środowiska Model aplikacji testowej Implementacja aplikacji testowej dla platformy IBM WebSphere Przygotowanie środowiska wykonawczego przykładowej aplikacji Implementacja aplikacji Implementacja modułu PEP Implementacja aplikacji testowej dla platformy Oracle SOA Suite Przygotowanie środowiska wykonawczego przykładowej aplikacji Instalowanie usługi Oracle Web Service z wykorzystaniem agenta serwera Instalowanie agentów klientów Implementacja modułu PEP Moduł PEP jako krok polityki Konstrukcja modułu PEP Definiowanie szablonu kroku Problemy implementacyjne Implementacja aplikacji testowej dla platformy Microsoft WCF Przygotowanie środowiska wykonawczego przykładowej aplikacji Warstwa Contracts Warstwa Service runtime Warstwa Messaging Dodawanie modułu PEP do aplikacji Implementacja aplikacji Program kliencki Implementacja modułu PEP Stany modułu PEP Interakcja modułu PEP z PDP Interakcja między modułami PEP Architektura modułu PEP w WCF Zarządzanie pamięcią w PEP Podsumowanie Bibliografia Wykaz skrótów i słowniczek pojęć...60 Politechnika Poznańska /62

3 Streszczenie Niniejszy raport przedstawia wyniki prac implementacyjnych prowadzonych nad prototypem środowiska ORCA. Prace te stanowią jeden z elementów realizacji zadania OB7 5: Języki definiowania polityki bezpieczeństwa dla SOA w Etapie 2 Fazy 1 (okres czerwiec grudzień 2009 r.) prac obszaru OB7: Zarządzanie środowiskiem i aplikacjami SOA projektu ITSOA. Raport omawia również ewolucję implementacji prototypu opracowaną w czasie testów funkcjonalnych prototypu przeprowadzonych w Etapie 3 prac badawczych (okres styczeń czerwiec 2010 r.). Politechnika Poznańska /62

4 1. Wstęp W przypadku systemów rozproszonych problematyka bezpieczeństwa przetwarzania danych i komunikacji od wielu lat odgrywa jedną z kluczowych ról w konstrukcji i implementacji zarówno samych aplikacji, jak i środowiska ich pracy. Trudność rozwiązywania problemów bezpieczeństwa rośnie wraz ze skalą rozproszenia systemu i jego heterogenicznością. Dodatkowym czynnikiem, współcześnie zyskującym na wadze, są coraz częstsze przypadki realizacji przetwarzania w środowisku obejmującym różne domeny administracyjne. Rodzi to na ogół potrzebę zdefiniowania wymagań odnośnie bezpieczeństwa, niezależnie od samego przetwarzania, w postaci polityki bezpieczeństwa. Przypadek ten dotyczy w szczególności systemów rozproszonych zorientowanych na usługi, w których przetwarzanie jest realizowane przy pomocy kompozycji (o strukturze niekiedy bardzo złożonej) wielu niezależnych usług, podlegających pod oddzielne domeny administracyjne posiadające odmienne wymagania odnośnie bezpieczeństwa. Architektura SOA (ang. Service Oriented Architecture [1]) odwzorowuje koncepcję przetwarzania rozproszonego zorientowanego na usługi, która zyskuje coraz szersze zainteresowanie w środowisku naukowym i, co równie doniosłe, na rynku informatycznym, czego dobitnym wyrazem jest wsparcie niewątpliwych potentatów tego rynku, jak IBM, Oracle, Microsoft oraz wielu innych. Mnogość dostępnych technologii i trudności w ich wzajemnej współpracy rodzą potrzebę wypracowania i rozpropagowania standardowych rozwiązań. Organizacje, które podjęły się tego zadania, w tym W3C (World Wide Web Consortium [2]), OASIS (Organization for the Advancement of Structured Information Standards [3]) czy WS I (Web Services Interoperability Organization [4]), opracowały już obszerny zbiór standardów łącznie z szeregiem rekomendacji i scenariuszy (ang. profiles) wykorzystania. Paradygmat SOA jest obecnie powszechnie implementowany poprzez zbiór technologii określanych wspólnie jako Web Services (WS). Architektura Web Services [10] dostarcza koncepcyjnego modelu realizacji usług WS i definiuje relacje pomiędzy komponentami danego modelu. Społeczność WS (w tym w szczególności organizacje W3C, OASIS czy WS I) dostarcza standardy i profile służące tworzeniu współoperatywnych aplikacji WS działających na różnych platformach. Przykładowo, przyjmuje się że interfejs serwisu WS jest opisany w formacie WSDL [13], a komunikacja odbywa się poprzez protokół SOAP [14] bazujący na składni XML [11], w połączeniu z innymi standardowymi mechanizmami WWW. Język XML oferuje standardowy, elastyczny format danych, kluczowy dla technologii WS. Z kolei protokół SOAP dostarcza standardowych mechanizmów do wymiany wiadomości XML. Natomiast WSDL dostarcza opisu interfejsu serwisu łącznie z abstrakcyjnym opisem wymiany wiadomości pomiędzy agentami (aplikacjami) i powiązaniem z konkretnym protokołem transportowym oraz formatem wiadomości. Koncepcja WS jest pewnym rozwinięciem modelu usługi WWW, alternatywnym wobec REST (REpresentation State Transfer [15]). Model WWW (a z nim i REST) narzuca tylko kilka ograniczeń dotyczących komunikacji: obiekty w systemie identyfikowane są poprzez unikalny adres URI (Uniform Resource Identifiers), zasoby mogą być reprezentowane poprzez różnorodne, powszednie rozumiane formaty Politechnika Poznańska /62

5 danych (XML, HTML, CSS itp.) oraz komunikacja odbywa się poprzez protokoły wykorzystujące adresy URI do identyfikacji zarówno bezpośrednich jak i pośrednich adresów usług i zasobów. Cel i zakres raportu Jednym z najistotniejszych aspektów zarządzania środowiskiem rozproszonym o architekturze SOA jest niewątpliwie definicja i realizacja polityki bezpieczeństwa. Niestety istniejące języki definicji polityki bezpieczeństwa dla środowisk rozproszonych nie uwzględniają wszystkich wymagań specyficznych dla SOA [6], zatem niezbędne jest zaproponowanie nowego języka. W pracy [5] zaproponowano taki język oraz architekturę środowiska realizacji polityki o nazwie ORCA. Niniejszy raport przedstawia projekt i implementację prototypu środowiska ORCA. Ponieważ prototyp poddawany był testom funkcjonalnym i wielokrotnie ewoluował, efekty tej ewolucji, w postaci odpowiednich optymalizacji architektury i protokołów środowiska, również znalazły się w bieżącym raporcie. Treść raportu powołuje się w wielu miejscach na koncepcję architektury i projekt środowiska ORCA szczegółowo przedstawione w raporcie TR ITSOA OB7 5 PR [5]. Struktura raportu Struktura raportu jest następująca. W rozdziale 2 pokrótce przedstawiono model prototypowego środowiska i aplikacji testowych. W kolejnych rozdziałach przedstawiono wyniki prac implementacyjnych na różnych platformach aplikacyjnych, w kolejności IBM WebSphere (rozdział 3), Oracle SOA suite (rozdział 4) i Microsoft WCF (rozdział 5). Rozdział 6 zawiera krótkie podsumowanie prac. Politechnika Poznańska /62

6 2. Model środowiska, przykładowe polityki i metody weryfikacji (aplikacje eksperymentalne) 2.1 Architektura prototypowego środowiska W tym rozdziale przedstawiona zostanie architektura prototypu środowiska ORCA. Prototyp środowiska posiada architekturę zawężoną w stosunku do docelowej propozycji [5]. Zbiór narzędzi został zawężony do tych, które są niezbędne dla zweryfikowania prostych interakcji realizowanych w przestrzeni pojedynczej domeny, z uwzględnieniem jednakże zagnieżdżenia wywołań, typowego dla przetwarzania w SOA. Architekturę prototypu przedstawia Rysunek 1. PAP PIB repository PDP Client PEP SOAP PEP Service S1 PEP Service S2 PEP Service S3 Rysunek 1. Architektura prototypowego środowiska Politechnika Poznańska /62

7 W prototypowym środowisku realizowana będzie prosta polityka bezpieczeństwa opisująca jednego użytkownika korzystającego z aplikacji klienta (Client) oraz 3 usługi (Service S1, S2 i S3). Użytkownik identyfikowany jest nazwą JBond. Uwierzytelniany jest przy pomocy hasła lub certyfikatu X.509. Usługi zlokalizowane są pod adresami odpowiednio oraz Wsparcie dla zagnieżdżonych wywołań usług ze strony języka polityki bezpieczeństwa wymaga obsługi delegacji uprawnień, mechanizmu typowo wykorzystywanego w przypadkach takich wywołań. Podstawowym celem testów przeprowadzanych w zaprojektowanym środowisku prototypowym będzie zweryfikowanie uwierzytelniania i autoryzacji dostępu do usług w przypadku dostępu bezpośredniego oraz delegacji. Przykładową politykę dla aplikacji testowej pracującej w prototypowym środowisku przedstawia Listing 1. Listing 1. Polityka dla aplikacji testowej 1. User JBond can authenticate with {username, X.509certificate}. 2. User JBond requires to sign with {xmlsig#hmac-sha1}. 3. Service requires to authenticate with {X.509certificate}. 4. Service can encrypt with {xmlenc#tripledes-cbc, xmlenc#aes128-cbc}. 5. Service can sign with {xmlsig#hmac-sha1}. 6. User JBond can access service for invocation. 7. User JBond can delegate service for service 8. Service can access service for invocation, on behalf of user JBond. Kluczowym elementem środowiska realizacji polityki bezpieczeństwa związanym z aplikacjami (w tym przypadku z aplikacją testową) jest moduł wykonawczy PEP (Policy Enforcement Point), kontaktujący się z usługą decyzyjną PDP (Policy Decision Point). Zadaniem PEP jest przechwytywanie wiadomości aplikacyjnych (np. SOAP) wymienianych w komunikacji realizowanej przez podmioty interakcji i wykonanie operacji niezbędnych dla zachowania zdefiniowanej polityki bezpieczeństwa. Obejmuje to m.in. negocjację parametrów ochrony komunikacji (np. szyfrowanie czy podpisywanie wiadomości aplikacyjnych) oraz pośrednictwo w realizacji uwierzytelniania i kontroli dostępu przeprowadzanych przez PDP. Interakcję PEP PDP opisuje protokół ORCA_PEP PDP. Listing 2 przedstawia schemat wymiany komunikatów tego protokołu. Listing 2. Schemat interakcji PEP PDP preparation 1. PEP S PDP: ORCA_REQ register_target (Service) 2. PEP S PDP: ORCA_RESP register_target (Target, Obligations, Capabilities) 3. PEP C PDP: ORCA_REQ register_subject (Client) 4. PEP C PDP: ORCA_RESP register_subject (Subject, Obligations, Capabilities) request processing Politechnika Poznańska /62

8 5. Client : SOAP_REQ (Session, Originator, Subject, Target, Action, subject_attributes) 6. PEP C PDP: ORCA_REQ register_subject (Originator) 7. PEP C PDP: ORCA_RESP register_subject (Originator, Obligations, Capabilities) 8. Service: SOAP_REQ (Session, Originator, Subject, Target, Action, subject_attributes) 9. PEP S PDP: ORCA_REQ policy_decision (Subject, Target, Action, subject_attributes, target_attributes) 10. PEP S PDP: ORCA_REQ policy_decision (Decision) 11. Client Service: SOAP_RESP (Subject, Target) Strukturę wiadomości przesyłanych przez protokół ORCA_PEP PDP prezentują kolejne listingi (Listing 3 Listing 6). Mając na uwadze elastyczność protokołu i z uwzględnieniem ewentualności dalszych rozszerzeń prototypu, przyjęto, że format wiadomości będzie bazował na języku XML. Listing 3. Format wiadomości ORCA_REQ register_subject oraz register_target <s:envelope xmlns:s=" <s:header> <Action s:mustunderstand="1" xmlns=" /> <ActivityId CorrelationId="17cb547e-40e ad5-39c " xmlns=" 890dcbd3-ceb6-454c-bd99-e74a993af526</ActivityId> </s:header> <s:body xmlns:xsi=" xmlns:xsd=" <orca_subject_register_req xmlns=" <orcasubject xmlns=""> <subjectid>jbond</subjectid> </orcasubject> </orca_subject_register_req> </s:body> </s:envelope> Listing 4. Format wiadomości ORCA_RESP register_subject oraz register_target <S:Envelope xmlns:s=" <s:header xmlns:s=" /> <S:Body> <ns2:registersubjectresponsexmlns:ns2=" <return> <subjectid>jbond</subjectid> <obligations> <action>sign</action> <method>xmlsig#hmac-sha1</method> </obligations> <capabilities> <action>authenticate</action> <method>username,x.509certificate</method> </capabilities> </return> </ns2:registersubjectresponse> Politechnika Poznańska /62

9 </S:Body> </S:Envelope> Listing 5. Format wiadomości ORCA_REQ policy_decision <s:envelope xmlns:s=" <s:header> <Action s:mustunderstand="1" xmlns=" /> <ActivityId CorrelationId="99374fed-e52a e36-b08ea7894c4b" xmlns=" d9f39a8b-ab4e-4f5f-aece-dcf4ef565fb2</activityid> </s:header> <s:body xmlns:xsi=" xmlns:xsd=" <getpolicydecision xmlns=" <orcapolicyreq xmlns=""> <messageid>9dc0effc-060a-4c80-baac e16b23</messageid> <originator>jbond</originator> <invoker>jbond</invoker> <subjects> <subjectid>jbond</subjectid> <subjectdetails> <attributename>username</attributename> <attributevalue>jbond</attributevalue> </subjectdetails> <subjectdetails> <attributename>password</attributename> <attributevalue>1234</attributevalue> </subjectdetails> </subjects> <actionname>getcaserecord</actionname> <action> <parametername>0</parametername> <parametervalue>nazwisko</parametervalue> </action> <targetid> </orcapolicyreq> </getpolicydecision> </s:body> </s:envelope> Listing 6. Format wiadomości ORCA_RESP policy_decision <S:Envelope xmlns:s=" <s:header xmlns:s=" /> <S:Body> <ns2:getpolicydecisionresponse xmlns:ns2=" <return> <decision>allow</decision> <decisiontime> t01:52: :00</decisiontime> </return> </ns2:getpolicydecisionresponse> </S:Body> </S:Envelope> Politechnika Poznańska /62

10 W implementacji prototypu środowiska ORCA przyjęto, że informacje o sesji zapoczątkowanej przez klienta są propagowane w głąb zagnieżdżonych wywołań przez proces zlecający wywołanie (Invoker), w żądaniu SOAP, w nagłówku <message>. Informacje te obejmują pola session_id nadawane przez oryginalnego klienta (Originator) oraz message_id nadawane przez wywołującego. Moduły PEP, podczas interakcji pomiędzy podmiotami kontrolowanymi przez siebie, dokładają do żądań i odpowiedzi SOAP nagłówek <orca> zawierający informacje niezbędne w czasie podejmowania decyzji (przez PDP) do identyfikacji podmiotów i ich atrybutów (a które to informacje nie muszą być przekazywane jawnie w kopercie SOAP przez procesy aplikacyjne uczestniczące w interakcji). Listing 7. Format nagłówka ORCA żądania SOAP generowanego przez klienta <orca> <originator id= JBond /> <invoker id="s1"/> <subject id="jbond"> <subject_attribute name="username"> JBond </subject_attribute> <subject_attribute name="password"> JBond_password </subject_attribute> </subject> </orca> <message> <session_id> </session_id> <message_id> </message_id> </message> Listing 8. Format nagłówka SOAP w odpowiedzi na żądanie klienta. <message> <session_id> </session_id> <message_id> </message_id> </message> Konfiguracja modułu PEP Istotną cechą modułu PEP jest jego konfigurowalność. Należy zauważyć, iż moduł ten powinien być przenaszalny między różnymi wdrożeniami środowiska ORCA i nie powinno to wymagać rekompilacji. Osiągnięto to m.in. poprzez wprowadzenie pliku konfiguracyjnego, którego strukturę obrazuje Listing 9. Znacznik <PDP_uri> zawiera fizyczną lokalizację PDP. Wartość w polu <PDP_name> wskazuje na nazwę podmiotu certyfikatu PDP (ang. common name). Jest ona opcjonalna i w przypadku jej braku za Politechnika Poznańska /62

11 nazwę podmiotu uznaje się część wartości z pola <PDP_name> wyekstrahowaną za pomocą wyrażenia regularnego:.*/(?<name>\w+)\?wsdl (dla przykładu z poniższego listingu będzie to PDPConnector). Wartość w polu <PEP_name> wskazuje na nazwę podmiotu certyfikatu PEP. Wartość ta jest również opcjonalna i w przypadku jej braku, PEP automatycznie uznaje jako nazwę podmiotu wartość z <PrincipalName>. Pole to (PrincipalName) określa nazwę konkretnego klienta bądź serwisu. Nazwa ta wykorzystywana jest np. podczas rejestracji w PDP. Pola <UsernameToken> oraz <Certificate> wskazują na lokalizację danych uwierzytelniających w kopercie SOAP. Listing 9. Plik konfiguracyjny PEP <?xml version="1.0" encoding="iso "?> <ConfigStructure> <PDP_uri> <PDP_name>ORCA1</PDP_name> <PEP_name>ORCA2</PEP_name> <Principal> <PrincipalName> <PrincipalCredentials> <UsernameToken>Header/Security/UsernameToken</UsernameToken> <Certificate>Header/Security/Signature/KeyInfo/SecurityToken Reference/KeyIdentifier/@ValueType</Certificate> </PrincipalCredentials> </Principal> </ConfigStructure> Architekturę wewnętrzną PEP przedstawia Rysunek 2. Składa się ona (niezależnie od konkretnej implementacji dla danej platformy aplikacyjnej) z kilku modułów funkcjonalnych opisanych poniżej. Politechnika Poznańska /62

12 PDP Service SOAP REQ PEP REQ_composer RESP_executor Encryptor Decryptor Signer Sig_verifier Token_codec Token_validator Obl_cache Cap_cache Cert_decoder X.509_validator Token_cache Cert_cache Key_cache Resources Attribute_retriever Rysunek 2. Architektura modułu PEP Moduły funkcjonalne PEP mają następującą charakterystykę: Token_decoder jest modułem odpowiedzialnym za wydobycie z wiadomości aplikacyjnych tokenów WSS (WebService Security [16]) zawierających np. certyfikaty podmiotów, ich klucze publiczne lub dowolne asercje bezpieczeństwa. o Cert_decoder odpowiada za zdekodowanie (deserializację) tekstowej postaci tokenu WS Security zawierającego certyfikat X.509 zakodowany metodą base64 (aktualnie jest to jedyna obsługiwana metoda kodowania) do postaci obiektu binarnego poddawanego dalszym procesom przetwarzania (np. weryfikacji ważności) Token_validator moduł realizujący weryfikację ważności zdekodowanych tokenów WSS o X.509_validator moduł realizujący lokalnie podstawową weryfikację poprawności certyfikatu X.509 (weryfikujący np. jego aktualność) Token_cache pamięć podręczna zdekodowanych uprzednio tokenów, które mogą być wykorzystywane w przyszłości; obejmuje ona o Cert_cache cache dla certyfikatów podmiotów (propagowanych przypadku zagnieżdżenia wywołań) o Key_cache cache dla kluczy kryptograficznych podmiotów wykorzystywanych do operacji związanych z ochroną komunikacji Attribute_retriever moduł odpowiedzialny za wydobycie z wiadomości aplikacyjnej lub ze środowiska wykonawczego aplikacji atrybutów (z wiadomości wydobywane są atrybuty podmiotów, a ze środowiska Politechnika Poznańska /62

13 wykonawczego atrybuty zasobów, do których realizowany jest dostęp); atrybuty te mogą być parametrami predykatów wykorzystywanych w regułach polityki, które dotyczą realizowanych operacji dostępu Obl_cache cache dla reguł typu Obligations odebranych uprzednio od PDP (w komunikatach ORCA_RESP register_subject oraz register_target) Cap_cache cache dla reguł typu Capabilities odebranych uprzednio od PDP (w komunikatach ORCA_RESP register_subject oraz register_target) REQ_composer moduł budujący żądania kierowane do PDP (ORCA_REQ register_subject, ORCA_REQ register_target i ORCA_REQ policy_decision) RESP_executor moduł odbierający odpowiedzi od PDP i umieszczający otrzymane dane (jak Obligations i Capabilities) w pamięci podręcznej Encryptor, Decryptor moduły realizujące operacje kryptograficzne związane z ochroną poufności komunikacji (szyfrowanie/deszyfrowanie wiadomości aplikacyjnych) Signer, Sig_verifier moduły realizujące operacje kryptograficzne związane z ochroną integralności i autentyczności komunikacji (podpisywanie wiadomości aplikacyjnych i weryfikację podpisów). 2.2 Model aplikacji testowej W celu zrealizowania eksperymentu praktycznego na prototypie środowiska ORCA przygotowano projekt obejmujący aplikację klienta (Client) oraz 3 usługi (Service S1, S2 i S3). Model tych aplikacji zgodnych z architekturą prezentowaną wcześniej (Rysunek 1) opisuje niniejszy punkt. Opisy implementacji aplikacji testowych dla poszczególnych platform znajdują się w kolejnych rozdziałach. Ze względu na niezależność modułów PEP od funkcjonalności aplikacji możliwy jest wybór dowolnej przykładowej aplikacji w celu przeprowadzenia testów. Na potrzeby implementacji testowej przyjmiemy, że: Service S1 Centralny Rejestr Danych Medycznych dostarcza klientowi uprawnionym odbiorcom informacji na temat historii choroby pacjenta; w aplikacji testowej informacje te obejmują numer ubezpieczenia (pobierany z usługi zagnieżdżonej Service 2) oraz nazwiska lekarza pierwszego kontaktu (z usługi zagnieżdżonej Service 3) dla danego pacjenta. Service S2 Rejestr NFZ na podstawie nazwiska pacjenta określa numer jego ubezpieczenia. Service S3 Przychodnia lekarska na podstawie nazwiska pacjenta określa dane jego lekarza. Client to program kliencki, który od użytkownika pobiera nazwisko pacjenta oraz dane uwierzytelniające (plik z certyfikatem X.509) i wyświetla pozyskaną od usługi Service 1 historię choroby. Na potrzeby aplikacji testowej przyjmujemy, że w systemie istnieje: Politechnika Poznańska /62

14 użytkownik uprawniony do korzystania z usługi S1 (operator programu klienta), o identyfikatorze JBond, użytkownik posiada certyfikat X.509 wystawiony przez usługę S1 i zapisany w pliku lokalnie dostępnym dla programu klienta, pacjent Sherlock Holmes o numerze ubezpieczenia przechowywanym i udostępnianym w ramach usługi S2, z którym usługa S3 kojarzy nazwisko lekarza dr Watson. Politechnika Poznańska /62

15 3. Implementacja aplikacji testowej dla platformy IBM WebSphere IBM WebSphere Application Server oraz IBM WebSphere Application Server Toolkit to dwa produkty firmy IBM wspierające implementację aplikacji zgodnych z paradygmatem SOA. IBM WebSphere Application Server umożliwia nam również odseparowanie modułów dotyczących bezpieczeństwa od implementacji czy funkcjonalności usługi. 3.1 Przygotowanie środowiska wykonawczego przykładowej aplikacji IBM WebSphere Application Server Toolkit umożliwia tworzenie schematu usługi opierając się na pliku WSDL stworzonym dla tej usługi, bądź też pliku WSDL innej usługi, która pełni rolę serwisu dla danej aplikacji. Najprościej więc zacząć od najbardziej zagnieżdżonych usług. 3.2 Implementacja aplikacji W środowisku IBM WebSphere zaimplementowano usługi zagnieżdżone (S2 oraz S3) przykładowej aplikacji opisanej w rozdziale 2.2. Implementacja usług składa się z trzech podstawowych kroków: Tworzenie ogólnego szkieletu usługi Utworzenie pliku WSDL oraz wygenerowanie na jego podstawie szkieletu danej usługi Implementacja funkcjonalności. Tworzenie ogólnego szkieletu W programie IBM WebSphere Application Server Toolkit należey ustawić perspektywę pracy na J2EE (Okna > Otwórz perspektywę > inne > J2EE). Następnie tworzymy dynamiczny projekt WWW (w oknie Eksplorator projektów prawym przyciskiem myszy > Nowy > Dynamiczny projekt WWW). Istotne jest by powiązać dany projekt z projektem EAR (przyjmuje się ze nazwa projektu EAR jest rozwinięciem nazwy projektu WWW o EAR ). W aspektach projektu należy wybrać moduły, które zostaną dołączone do projektu (domyślnie są to: Dynamiczny moduł WWW, moduł Java, i dwa moduły WWW WebSphere i te są niezbędne; w razie zapotrzebowania można dołączyć jeszcze inne). Politechnika Poznańska /62

16 Tworzenie pliku WSDL W środowisku IBM WebSphere istnieje kilka możliwości edycji pliku WSDL, np.: poprzez tekstową modyfikację pliku XML, za pomocą graficznego interfejsu czy urządzenia do modyfikacji plików XML (udostępnionych w IBM WebSphere Application Server Toolkit). W katalogu WebContent/WEB_INF tworzymy folder o nazwie wsdl. W utworzonym folderze tworzymy plik wsdl (prawy przycisk myszy na folderze > Nowy > Inne > Usługi WWW > WSDL). Teraz możemy wybrać sposób modyfikowania tego pliku. Domyślnie plik otwiera się w edytorze WSDL ale mamy też inne opcje (prawy przycisk myszy na pliku > Otwórz za pomocą). Modyfikacji dokonujemy zgodnie z zewnętrzną funkcjonalnością usługi jaką chcemy osiągnąć (określamy np.: metody jakie będą mogły być wywoływane zdalnie, ich parametry wejściowe i wyjściowe ). W przypadku usługi Service2 tworzymy metodę o nazwie NrUbezpieczenia, gdzie parametrem wejściowym jest String (nazwisko pacjenta) a parametrem wyjściowym int (numer ubezpieczenia). W przypadku usługi Service3 tworzymy metodę o nazwie NazwiskoLekarza, gdzie parametrem wejściowym jest String (nazwisko pacjenta) oraz parametrem wyjściowym jest również String (naywisko lekarza). Generowanie szkieletu usługi na podstawie pliku WSDL W oknie Eksplorator projektów prawym przyciskiem myszy na plik WSDL > Usługi WWW > Generuj Szkielet komponentu Java Bean. Definiujemy usługę na poziomie uruchamiania. Zaznaczamy brak klienta. Implementacja funkcjonalności Po wykonaniu powyższych działań w katalogu WebContent/WEB_INF pojawi się katalog classes a w nim istotna dla nas klasa: Service2WSDLFileSOAPImpl i odpowiednio dla drugiego projektu Service3WSDLFileSOAPImpl. Są to klasy które zawierają zdefiniowane przez nas metody: NrUbezpieczenia oraz NazwiskoLekarza. W celu zapewnienia wymaganej funkcjonalności pozostaje tylko uzupełnić je odpowiednim kodem (kody tych klas znajdują się w odpowiadających im plikach w katalogu src/ projektu). Implementacja usługi głównej (S1) Implementacja usługi S1 składa się z 4 podstawowych kroków : Tworzenie ogólnego szkieletu usługi identycznie jak dla usług zagnieżdżonych. Politechnika Poznańska /62

17 Wskazanie relacji tej usługi z jej usługami zagnieżdżonymi. Tworzenie pliku WSDL identycznie jak dla usług zagnieżdżonych. Implementacja funkcjonalności. Relacja S1 z usługami zagnieżdżonymi W tym punkcie bazując na plikach WSDL usług zagnieżdżonych (S2 i S3) utworzymy klasy umożliwiające komunikację z tymi usługami. Klasy niezbędne do komunikacji z usługą S2: prawym przyciskiem myszy na pliku WSDL usługi Service2 > Usługi WWW > Generuj klienta Ustawiamy Klient wdrożenia. Projekt klienta : wskazujemy Service1 (musimy go wcześniej utworzyć). Projekt EAR klienta : wskazujemy Service1EAR. Identycznie postępujemy dla ustanowienia komunikacji z usługą S3. W wyniku tych działań w katalogu src projektu został wygenerowany szereg klas wspomagających komunikację z usługami S2 oraz S3. Dla naszego przykładu najistotniejsze są to: Service2WSDLFile_PortTypeProxy oraz Service3WSDLFile_ PortTypeProxy. Należy się do nich odwołać w celu nawiązania połączenia z usługami zagnieżdżonymi. Projekt klienta Na potrzeby naszego przykładu tworzymy niezależny projekt klienta usługi Service1(Standalone Client), choć równie dobrze mogłaby to być kolejna usługa. Tworzymy projekt klienta aplikacji (w oknie Eksplorator projektów prawym przyciskiem myszy Nowy Projekt klienta aplikacji). Następnie generujemy szkielet klienta na podstawie pliku WSDL usługi S1 i implementujemy funkcjonalność. 3.3 Implementacja modułu PEP Politechnika Poznańska /62

18 4. Implementacja aplikacji testowej dla platformy Oracle SOA Suite Oracle SOA Suite [8] to komercyjna platforma integrująca kilka produktów przeznaczonych do realizacji infrastruktury przetwarzania rozproszonego, wliczając w to Oracle Service Bus oraz Oracle Web Services Manager (OWSM). 4.1 Przygotowanie środowiska wykonawczego przykładowej aplikacji Przygotowanie środowiska wykonawczego aplikacji obejmowało instalację oraz konfigurację platformy Oracle SOA Suite 10g wraz z jej kluczowymi komponentami. Podstawowym elementem środowiska jest serwer aplikacyjny OC4J, umożliwiający wykonywanie kodu usług zaimplementowanych w technologii Web Services. Drugim ważnym komponentem środowiska jest Oracle Web Services Manager, pozwalający na centralne zarządzanie polityką bezpieczeństwa architektury zorientowanej na usługi poprzez przyporządkowywanie usługom punktów egzekwowania polityk PEP. W komponencie OWSM środowiska Oracle SOA Suite wyróżnić można dwa mechanizmy pomocne dla automatyzacji egzekwowania polityk bezpieczeństwa zastosowanie bramy (ang. gateway) lub systemu agentów dla aplikacji klienta i serwera (ang. client agents, server agents). W prototypie środowiska wybrano sposób z wykorzystaniem agentów. W ramach pracy przygotowano usługę S3. Przygotowaną usługę wdrożono na serwer aplikacyjny, a następnie dokonano rejestracji w OWSM. Instalowanie usługi Oracle Web Service z wykorzystaniem agenta serwera W celu wdrożenia agenta dla usługi (agent serwera) należy wykonać następujące kroki: 1. Utworzyć nowy komponent agenta serwera. 2. Zdefiniować politykę bezpieczeństwa dla utworzonego agenta. 3. Zainstalować agenta. 4. Skonfigurować deskryptor wdrożenia usługi (ang. Web service deployment descriptor). Szerszy opis wykonywanych kroków znajduje się poniżej. Tworzenie nowego komponentu agenta serwera Za pomocą konsoli sterowania (ang. Control Console) Web Services Manager należy zarejestrować agenta serwera wybierając w widoku Policy Management opcję Add New Component, a następnie przypisując jej następujące wartości z list wyboru: Component type Server Agent Politechnika Poznańska /62

19 Container type OC4J Następnie należy wybrać odnośnik Register. Spowoduje to wygenerowanie identyfikatora komponentu (component ID). Należy zapisać identyfikator, gdyż jego podanie będzie konieczne w następnych krokach. Rysunek 3. Tworzenie nowego komponentu agenta serwera W powyższym przykładzie (Rysunek 3) utworzono komponent agenta serwera o nazwie S3_server_agent. Komponent ten będzie chronił usługę S3_Przychodnia. Definiowanie polityki dla agenta serwera Za pomocą konsoli sterowania OWSM należy dokonać konfiguracji polityki, która zostanie powiązana z agentem. Opis mechanizmu polityk OWSM znaleźć można w [23]. Szczegóły definiowania polityk odnaleźć można w [17]. Przed utworzeniem polityki bezpieczeństwa, należy wzbogacić nasz punkt egzekwowania polityk (jakim jest komponent agenta serwera) o dodatkowy krok, będący implementacją rozwiązania wspierającego język ORCA. W tym celu w widoku głównym OWSM, na zakładce Policy Management należy wybrać odnośnik Steps dla danego komponentu (komponent o ID wygenerowanym podczas rejestracji). Politechnika Poznańska /62

20 Rysunek 4. Tworzenie nowego komponentu agenta serwera W następnym widoku zostanie nam zaprezentowana lista wszystkich udostępnianych przez OWSM kroków. Dodanie nowego kroku sprowadza się do wybrania opcji Add New Step, a następnie podania ścieżki do pliku.xml będącego szablonem kroku (ang. Step Template) ORCA_PEP. Rysunek 5. Dodawanie nowego kroku polityki dla komponentu agenta Politechnika Poznańska /62