Języki definiowania polityki bezpieczeństwa

Program Operacyjny Innowacyjna Gospodarka: Dział anie 1.3.1 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 narzędzi środowiska realizacji polityki bezpieczeństwa dla języka ORCA Bartosz Brodecki, Mateusz Falewicz, Piotr Sasak, Michał Szychowiak Sieć Naukowa Technologii Informacyjnych SOA

Informacje o dokumencie Numer raportu: Koordynator: Autorzy: Data: Poziom dostępności: Słowa kluczowe: TR ITSOA OB7 5 PR 09 08 0.14 Michał Szychowiak (PP) Bartosz Brodecki, Mateusz Falewicz, Piotr Sasak, Michał Szychowiak (PP) 2010 05 10 (ostatnie zmiany: Michał Szychowiak) wewnętrzny partnera bezpieczeństwo, implementacje SOA Numer raportu: TR ITSOA <numer OB>{PU PR} <rok utworzenia> <kolejny numer> Poziomy dostępności: Wewnętrzny partnera, wewnętrzny konsorcjum, publiczny Politechnika Poznańska 2010 10 11 2/26

Historia zmian w dokumencie 1 Wersja Data modyfikacji Zmodyfikowane przez Opis modyfikacji 0.1 2009 08 01 Michał Szychowiak (PP) Utworzenie dokumentu, struktura treści. 0.11 2009 11 12 Piotr Sasak(PP) Uspójnienie listingów komunikatów z opracowaniem 09 04 0.12 2009 11 28 Mateusz Falewicz (PP) Treść rozdziału 3 i 4, podrozdziały 4.1,4.2, 4.3 1.0 2009 12 31 Michał Szychowiak (PP) poprawki 1.1 2010 01 29 Mateusz Falewicz (PP) Kolejne treści, poprawki 1.17 2010 05 10 Mateusz Falewicz (PP) Rozwinięcie opisu formalnego zapisu reguł 1.2 2010 10 11 Michał Szychowiak (PP) poprawka linii delegacji (linia 7) w przykładowej polityce (Listing 1) do aktualnego formatu 1 Tylko do użytku wewnętrznego Politechnika Poznańska 2010 10 11 3/26

Spis treści Streszczenie...5 1. Wstęp...6 Cel i zakres raportu...7 Struktura raportu...7 2. Model architektury prototypowego środowiska...8 3. Platforma Apache Tomcat...13 3.1 Apache Tomcat... 13 4. Implementacja narzędzi środowiska prototypowego...14 4.1 PDP (Policy Decision Point)... 14 Interakcja PDP z PEP... 15 4.2 PAP (Policy Administration Point)... 16 4.3 PIB (Policy Information Base)... 17 Reprezentacja formalna reguł... 20 5. Podsumowanie...21 6. Bibliografia...22 7. Wykaz skrótów i słowniczek pojęć...24 Politechnika Poznańska 2010 10 11 4/26

Streszczenie Niniejszy raport przedstawia wyniki prac implementacyjnych prowadzonych nad narzędziami prototypu ś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. Politechnika Poznańska 2010 10 11 5/26

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 [16]). 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 2010 10 11 6/26

Cel i zakres raportu Struktura raportu 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. 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 wyniki prac implementacyjnych prowadzonych nad narzędziami prototypu środowiska ORCA. 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 09 04 [5]. 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. Rozdział 5 zawiera krótkie podsumowanie prac. Politechnika Poznańska 2010 10 11 7/26

2. Model architektury prototypowego środowiska W tym rozdziale przedstawimy dla porządku model prototypowej wersji środowiska ORCA, obejmujący podzbiór komponentów docelowej architektury przedstawionej w [5]. Komponenty te to (Rysunek 1): PAP Policy Administration Point, wykorzystywany jest do zdefiniowania reguł dostępu do zasobów, PIB Policy Information Base, repozytorium przechowujące polityki definiowane przez PAP, PDP Policy Decision Point, podejmuje decyzje o zatwierdzeniu żądania dostępu do zasobu w oparciu o reguły zawarte w PIB, PEP Policy Enforcement Point, generuje prośbę o decyzję do PDP i podejmuje odpowiednią akcję w związku konkretną otrzymaną odpowiedzią; moduły PEP, jakkolwiek dostarczane niezależnie do aplikacji (usług i ich klientów) muszą być w takim stopniu zintegrowane z aplikacjami, aby mogły pośredniczyć w komunikacji między nimi. PAP PIB repository PDP Client PEP SOAP PEP Service Rysunek 1. Architektura prototypowego środowiska Przykładową politykę dla aplikacji testowej pracującej w prototypowym środowisku przedstawia Listing 1. 1. User j_bond can authenticate with {username, X.509certificate}. 2. User j_bond requires to sign with {xmlsig#hmac-sha1}. 3. Service http://service.pl:1234/* requires to authenticate with {X.509certificate}. 4. Service http://service.pl:1234/* can encrypt with {xmlenc#tripledes-cbc, xmlenc#aes128-cbc}. 5. Service http://service.pl:1234/* can sign with {xmlsig#hmac-sha1}. Politechnika Poznańska 2010 10 11 8/26

6. User j_bond can access service http://service.pl:1234/s1 for invocation. 7. User j_bond can delegate to service http://service.pl:1234/s1 {any_access} for service http://service.pl:1234/*. 8. Service http://service.pl:1234/s1 can access service http://service.pl:1234/* for invocation, on behalf of user j_bond. 9. Service http://service.pl:1234/* can authenticate with {X.509certificate}. Listing 1. Polityka dla aplikacji testowej Interakcję PDP PIB opisuje protokół ORCA_PDP PIB. Listing 2 przedstawia schemat wymiany komunikatów tego protokołu. Formaty poszczególnych komunikatów przedstawiają kolejne listingi (Listing 3 Listing 6). 1. PEP PDP: ORCA_REQ register_subject (Client) 2. PDP PIB: ORCA_REQ fetch_oblig_cap (Client) 3. PDP PIB: ORCA_RESP fetch_oblig_cap (Subject, Obligations, Capabilities) 4. PEP PDP: ORCA_RESP register_subject (Subject, Obligations, Capabilities) 5. PEP PDP: ORCA_REQ register_target (Service) 6. PDP PIB: ORCA_REQ fetch_oblig_cap (Service) 7. PDP PIB: ORCA_RESP fetch_oblig_cap (Target, Obligations, Capabilities) 8. PEP PDP: ORCA_RESP register_target (Target, Obligations, Capabilities) 9. Client Service: SOAP_REQ (Subject, Target, Action, subject_attributes) 10. PEP PDP: ORCA_REQ policy_decision (Subject, Target, Action, subject_attributes, target_attributes) 11. PDP PIB: ORCA_REQ fetch_rules (Subject, Target[, Global_condition]) 12. PDP PIB: ORCA_RESP fetch_restr (Subject, Target, Restrictions) 13. PEP PDP: RESP policy_decision (Decision) Listing 2. Schemat interakcji PEP PDP oraz PDP PIB 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. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE orca_subject_register_req SYSTEM "orca_subject_register_req.dtd"> <orca_subject_register_req> <subject id="jbond" /> </orca_subject_register_req> Listing 3. Format wiadomości ORCA_REQ register_subject oraz register_target <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE orca_subject_register_resp SYSTEM "orca_subject_register_resp.dtd"> <orca_subject_register_resp> <subject id="http://service.pl:1234/*"> <obligations> <obligation_token> <action> Politechnika Poznańska 2010 10 11 9/26

authenticate </action> <method> X.509certificate </method> </obligation_token> </obligations> <capabilities> <capability_token> <action> sign </action> <method> xmlsig#hmac-sha1 </method> </capability_token> <capability_token> <action> encrypt </action> <method> xmlenc#tripledes-cbc </method> <method> xmlenc#aes128-cbc </method> </capability_token> </capabilities> </subject> </orca_subject_register_resp> Listing 4. Format wiadomości ORCA_RESP register_subject oraz register_target <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE orca_pep_req SYSTEM "orca_pep_req.dtd"> <orca_pep_req> <message_id> 34943549845 </message_id> <originator id="jbond"/> <invoker id="s1"/> <subjects> <subject id="jbond"> <subject_attribute name="username"> JBond </subject_attribute> <subject_attribute name="password"> JBond_password </subject_attribute> </subject> <subject id="s1"> <subject_attribute name="x509cert" EncodingType="Base64Binary"> X509Certificate_value_base64_encoded </subject_attribute> </subject> </subjects> Politechnika Poznańska 2010 10 11 10/26

<action name="patriot"> <action_parameter name="target_name"> UFO </action_parameter> <action_parameter name="target_coordinators"> 52W39N10000m </action_parameter> </action> <target id="s2"> </target> <invocation_time> 2009-09-12 23:23:10 </invocation_time> </orca_pep_req> Listing 5. Format wiadomości ORCA_REQ policy_decision <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE orca_policy_decision_resp SYSTEM "orca_policy_decision_resp.dtd"> <orca_policy_decision_resp> <decision> allow deny indeterminate </decision> <decision_time> 2009-09-12 23:23:10 </decision_time> </orca_policy_decision_resp> Listing 6. Format wiadomości ORCA_RESP policy_decision <orca> <subject id="jbond"> <subject_attribute name="username"> JBond </subject_attribute> <subject_attribute name="password"> JBond_password </subject_attribute> </subject> </orca> <message> <originator id= JBond /> <session_id> 3498459845 </session_id> <message_id> 34943549845 </message_id> </message> Listing 7. Format nagłówka ORCA żądania SOAP generowanego klienta <message> <originator id= JBond /> <session_id> Politechnika Poznańska 2010 10 11 11/26

3498459845 </session_id> <message_id> 34943549845 </message_id> </message> Listing 8. Format nagłówka SOAP w odpowiedzi na żądanie klienta Politechnika Poznańska 2010 10 11 12/26

3. Platforma Apache Tomcat Implementację narzędzi środowiska ORCA zrealizowano na platformie Apache Tomcat. Apache Tomcat jest kontenerem aplikacji webowych rozwijany w ramach projektu Apache. Wyróżniają go następujące cechy: 3.1 Apache Tomcat jest kontenerem serwletów uniwersalnego języka Java jest jednym z najbardziej popularnych kontenerów usług WWW jest to projekt open source (Apache Software License) rozwijany przez Apache Software Foudation i niezależnych ochotników Instalacja serwera Tomcat w systemie Windows może odbyć się na dwa sposoby za pomocą gotowego pliku instalacyjnego, oraz poprzez rozpakowanie archiwum. Pierwszy sposób charakteryzuje się tym, że Apache Tomcat instalowany jest jako usługa systemu Windows, która uruchamia się wraz ze startem systemu. W drugim przypadku konieczne jest ręczne uruchomienie za pomocą skryptu startup.bat z podkatalogu bin (względem głównego katalogu, w którym zainstalowano serwer Tomcat) Politechnika Poznańska 2010 10 11 13/26

4. Implementacja narzędzi środowiska prototypowego W tworzeniu narzędzi wykorzystano technologie Java EE i Java SE oraz bazę danych PostgreSQL. 4.1 PDP (Policy Decision Point) Moduł PDP został zrealizowany jako Web Service, udostępniając metody umożliwiające komunikację z modułami PEP (Policy Enforcement Point). Rysunek 2. Metody klasy PDPConnector Główną klasą odpowiedzialną za działanie modułu jest klasa PDPConnector. Udostępnia ona metody: registersubject, registertarget, getpolicydecision. Pierwsze dwie umożliwiają odpowiednio rejestrację danego użytkownika/serwisu/roli, zwracając Obligations i Capabilities danego obiektu. Metoda getpolicydecision na podstawie dostarczonych danych wywołującego serwis i danych serwisu/zasobu, który to ma zostać wywołany, decyduje o przyznaniu dostępu do serwisu/zasobu. Informacje o tym, jakie prawa ma obiekt i czy posiada dostęp do danego serwisu, pobierane są przez PDP z repozytorium danych PIB (Policy Information Base). Politechnika Poznańska 2010 10 11 14/26

Interakcja PDP z PEP Komunikację PDP PEP obrazuje schematycznie Rysunek 3. Rysunek 3. Diagram sekwencji obrazujący komunikację PEP z PDP Pierwszym etapem w komunikacji jest moment rejestracji wymagany jest zarówno ze strony klienta jak i ze strony usługi. W momencie wywołania usługi przez klienta, fakt ten przechwycony jest przez moduł PEP dołączony do klienta i Politechnika Poznańska 2010 10 11 15/26

wywoływana jest metoda getpolicydecision. W tym momencie następuje wymiana wiadomości pomiędzy PDP a PIB, w wyniku której PIB zwraca dane dotyczące klienta i jego praw. Na podstawie tych danych PDP decyduje o przyznaniu dostępu do zasobu. W przypadku zezwolenia na dostęp (odpowiedź allow ) wywołanie usługi kończy się sukcesem i odpowiedź zwracana jest do obiektu wywołującego daną usługę. W przeciwnym wypadku (odpowiedź deny) do klienta odsyłany jest komunikat o braku wystarczających praw dostępu do usługi. O przyznaniu bądź odrzuceniu dostępu do danej usługi decyduje kolejność reguł jeśli w zwróconych regułach jako pierwsza znajdzie się taka, która zdecyduje o odrzuceniu dostępu, taka będzie ostateczna decyzja PDP. 4.2 PAP (Policy Administration Point) Moduł PAP zrealizowany został w technologii Java SE; umożliwia on wprowadzanie reguł polityki bezpieczeństwa w języku ORCA. Po zatwierdzeniu zmian reguły te uwzględniane są w polityce bezpieczeństwa następuje ich przesłanie do PIB. Rysunek 4. Widok modułu PAP Moduł ten wykorzystuje dostarczone przez PIB usługi WS retrievepolicy dla pobierania treści polityki bezpieczeństwa oraz odpowiednio savepolicy do zapisu. Polityka bezpieczeństwa pobierana jest w całości i wyświetlana użytkownikowi po jej edycji następuje nadpisanie wszystkich istniejących reguł w bazie. Dzięki temu utrzymana jest spójność polityki. Kluczowym elementem aplikacji PAP jest komponent JSyntaxPane (http://code.google.com/p/jsyntaxpane/ ). JSyntaxPane to kontrolka edycji tekstu zrealizowana w technologii Swing, umożliwiająca kolorowanie składni na podstawie lexerów wygenerowanych przez narzędzie JFlex (http://jflex.de/). Uzupełnienie funkcjonalności komponentu JSyntaxPane o obsługę kolorowania Politechnika Poznańska 2010 10 11 16/26

składni języka ORCA polegało na opracowaniu pliku wzorców (plik taki zawiera wyrażenia regularne oraz fragmenty kodu Java, a jego format jest zgodny z formatem popularnego w systemach uniksowych programu lex). Następnie za pomocą programu JFlex wygenerowano lexer (w postaci kodu Java), który dołączono do projektu JSyntaxPane i zintegrowano z kontrolką. Integracja obejmowała dodanie do kodu projektu tzw. syntax kit (w pakiecie jsyntaxpna.syntaxkits), będącego klasą języka Java, wywołującą klasę lexera języka ORCA. Dokonano również uzupełnień w oryginalnej konfiguracji komponentu w plikach o rozszerzeniach.properties (jsyntaxpane.config.properties, jsyntaxpane.javasyntaxkit.properties, jsyntaxpane.syntaxstyles.properties) celem zarejestrowania obsługi składni nowego języka oraz zdefiniowania różnego rodzaju formatowania dla poszczególnych typów tokenów (symboli reprezentujących grupy słów kluczowych zdefiniowanych w pliku wzorców). 4.3 PIB (Policy Information Base) W skład modułu PIB wchodzą dwa człony: aplikacja webowa (z usługami WS) i baza danych, z którą komunikacja przebiega za pomocą sterownika JDBC. Rysunek 5. Metody klasy PIBConnector Metody udostępniane przez PIB służą do komunikacji z dwoma pozostałymi modułami PDP i PAP. Metody fetchobligationscapabilities oraz fetchrules wykorzystywane są w momencie wymiany danych z PDP; pierwsza z nich zwraca obiekt zawierający dane na temat reguł Obligations i Capabilities dla żądanego obiektu. Dodatkowo zdefiniowany jest parametr type, który określa czy obiekt jest serwisem czy też użytkownikiem. W przypadku metody fetchrules zwraca ona reguły polityki bezpieczeństwa dotyczące danego podmiotu subject, który chce uzyskać dostęp do zasobów obiektu target, przy podanych warunkach conditions. Dla wymiany danych pomiędzy modułem PAP i PIB przygotowane zostały metody retrievepolicy oraz savepolicy. Pierwsza z nich zwraca aktualną wersję polityki bezpieczeństwa w postaci ciągu znaków; savepolicy służy do zatwierdzenia zmian w polityce i zapisania ich w bazie danych. Politechnika Poznańska 2010 10 11 17/26

Rysunek 6. Diagram klasy PolicyLoader Do transformacji reguł polityki z postaci tekstowej do postaci formalnej stworzona została osobna klasa PolicyLoader. Sprawdzana jest każda linia i po odpowiednim dopasowaniu reguł agregowana jest do kolekcji, w których znajdują się reguły tego samego typu. Klasa umożliwia następnie dostęp do danych za pomocą zbiorów kolekcji; są to już formalne postaci reguł. Jednak dla większej użyteczności, każdy obiekt posiada pole tekstowe z wersją pełną danej reguły wykorzystywane jest to przy zmianach w bazie danych. Politechnika Poznańska 2010 10 11 18/26

Rysunek 7. Schemat bazy danych PIB W bazie danych składowane są informacje dotyczące polityki bezpieczeństwa. Każda reguła polityki ma przypisaną osobną tabelę, w której jest przechowywana, w zależności od jej rodzaju. Można wydzielić część wspólną pól klucz główny, identyfikujący jednoznacznie regułę w obrębie danej tabeli, pole target/subject definiuje jakiego podmiotu dotyczy reguła, oraz pole klucza obcego, wskazujące na krotkę tabeli rules. Tabela rules przechowuje wszystkie reguły polityki bezpieczeństwa w formie pełnego tekstu. Wykorzystywane jest to w momencie komunikacji z modułem PAP, aby uniknąć nadmiarowej transformacji z postaci formalnej reguł zawartych w osobnych tabelach do postaci pełnego tekstu, zrozumiałego dla osoby zarządzającej polityką bezpieczeństwa (Security Officer). Politechnika Poznańska 2010 10 11 19/26

Tabele przechowujące formalne postaci reguł polityki bezpieczeństwa podzielone zostały na dwie grupy. Jedna, z nazwą kończącą się na _s dotyczy obiektów Subject, natomiast te z końcówką _t dotyczą obiektów typu Target. Typowo do pierwszej grupy należą użytkownicy i aplikacje klienckie, zaś do drugiej grupy usługi. Jednakże w przypadku zagnieżdżenia wywołań, gdy jedna usługa będzie żądać dostępu do innej, wtedy także ona będzie obiektem Subject. Relacje restriction i prohibition zawierają w sobie informacje bezpośrednio dotyczące dostępu do usługi/zasobu. Dane zawarte w tabeli restriction określają, jakie prawa posiada dany podmiot, tj. do jakich usług ma dostęp. Relacja prohibition określa jawne zakazy dostępu. Istnieje również tabela control, ściśle powiązana z tabelą rules.klucz główny tabeli control jest jednocześnie kluczem obcym wskazującym na wyszczególnioną regułę znajdującą się w tabeli rules, która powiązana jest z kolei z krotką znajdującą się w jednej z tabel przechowujących formalne wersje reguł. W tabeli control przechowywane są dane opisujące szczegóły reguł, takie jak: nazwa autora reguły, data utworzenia, oraz informacja czy dana reguła jest aktywna. Taka możliwość kontroli dostępu i edycji polityki bezpieczeństwa daje większe możliwości zarządzania. Reprezentacja formalna reguł Reguły zapisane w bazie danych wymagają by były zapisane w postaci formalnej. Przykładem jest zapisanie reguły typu restriction pokazane na poniższych listingach (Listing 9 i Listing 10). User j_bond can access service http://service.pl:1234/s1 for invocation. Listing 9. Przykładowa reguła restriction Restriction(1;"j_bond";"http://service.pl:1234/S1";"invoke";"none";288) Listing 10. Reprezentacja wewnętrzna (PIB) reguły z przykładu Listing 9 Pierwszy element (Listing 10) stanowi klucz podstawowy rekordu bazy; kolejne pole to subject, następne target. Następne wpisy informują kolejno o rodzaju akcji, warunkach (global condition) i ostatni element to klucz obcy wskazujący na krotkę w tabeli rules. Politechnika Poznańska 2010 10 11 20/26

5. Podsumowanie Niniejszy raport przedstawia wyniki prac implementacyjnych prowadzonych nad narzędziami prototypu środowiska ORCA: PAP, PIB oraz PDP. Kolejnym etapie realizacji projektu prototyp będzie badany i udoskonalany. Przewidziane jest również rozszerzenie implementacji środowiska o moduł PAL (Etap 3) oraz PIP (Etap 4). Politechnika Poznańska 2010 10 11 21/26

6. Bibliografia [1] MacKenzie C. Matthew, Laskey Ken, McCabe Francis, Brown Peter, Metz Rebekah: Reference Model for Service Oriented Architecture, OASIS Committee Draft 1.0, OASIS Open, 2006, http://www.oasis-open.org/committees/download.php/16587/wd-soa-rm-cd1ed.pdf. [2] World Wide Web Consortium (W3C), http://www.w3.org/. [3] OASIS Open, http://www.oasis open.org/. [4] Web Services Interoperability Organization (WS I), http://www.ws-i.org/. [5] Brodecki B., Brzeziński J., Sasak P., Szychowiak M., Design of ORCA security policy definition framework, Raport techniczny TR ITSOA OB7 5 PR 09 04, Politechnika Poznańska, grudzień 2009. [6] Brodecki B., Górecki S., Sasak P., Szychowiak M., Analiza własności języków definicji polityki bezpieczeństwa, Raport techniczny TR ITSOA OB7 5 PR 09 02, Politechnika Poznańska, maj 2009. [7] IBM WebSphere, http://www.ibm.com/software/websphere/. [8] Oracle SOA Suite, http://www.oracle.com/technologies/soa/soa-suite.html. [9] Windows Communication Foundation, Microsoft, http://msdn.microsoft.com/en-us/netframework/aa663324.aspx. [10] Booth David, Haas Hugo, McCabe Francis, Newcomer Eric, Champion Michael, Ferris Chris, Orchard David, Web Services Architecture, W3C Working Group Note, 2004, http://www.w3.org/tr/2004/note ws arch 20040211/. [11] Bray T., Paoli J., Sperberg McQueen C.M., Maler E., Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation, 2000, http://www.w3.org/tr/2000/rec-xml-20001006. [12] Fielding R., Gettys J., Mogul J., Frystyk H., Masinter L., Leach P., Berners Lee T., Hypertext Transfer Protocol HTTP/1.1, Request for Comments 2616, IETF Network Working Group, 1999 [13] Chinnici R., Gudgin M., Moreau J J., Schlimmer J., Weerawarana S., Web Services Description Language Version 2.0 Part 1: Core Language, W3C Working Draft, 2003, http://www.w3.org/tr/2003/wd wsdl20 20031110/. [14] Gudgin M., Hadley M., Mendelsohn N., Moreau J J., Nielsen H., SOAP Version 1.2 Part 1: Messaging Framework, W3C Recommendation, 2003, http://www.w3.org/tr/2003/rec-soap12-part1-20030624/. [15] Clement L., Hately A., von Riegen C., Rogers T., UDDI Version 3.0.2, UDDI Spec Technical Committee Draft, OASIS Open, 2004, http://uddi.org/pubs/uddi_v3.htm [16] Fielding R.T. Architectural Styles and the Design of Network based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000. Politechnika Poznańska 2010 10 11 22/26

[17] Cantor S., Kemp J., Philpott R., Maler E., Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Open, Mar 2005, http://docs.oasis-open.org/security/saml/v2.0/. [18] Nadalin A., Kaler Ch., Monzillo R., Hallam Baker P., Web Services Security: SOAP Message Security 1.1 (WS Security 2004), OASIS Open, Feb 2006, http://docs.oasis-open.org/wss/v1.1/. Politechnika Poznańska 2010 10 11 23/26

7. Wykaz skrótów i słowniczek pojęć Wykaz skrótów ACE ACL API ARL CA CARS CMP CSS DAC DACL DDoS DOM DoS DSML EAR EJB FTP GSS HMAC HTML HTTP IIOP IPC JAAS JAXB JAXM JAXP JAX RPC JAX WS JGSS JMS JRE JSF JSON JSP JSSE JVM LDAP LTPA MAC MIME MSMQ Access Control Entries Access Control List Application Programming Interface Access Rights List Certification Authority Common Auditing and Reporting Service Certificate Management Protocol Cascading Style Sheets Discretionary Access Control Discretionary Access Control List Distributed Denial of Service Document Object Model Denial of Service Directory Service Markup Language Enterprise ARchive Enterprise Java Beans File Transfer Protocol General Security Services keyed Hashing Message Authentication HyperText Markup Language HyperText Transfer Protocol Internet Inter ORB Protocol Inter Process Communication Java Authentication and Authorization Service Java Architecture for XML Binding Java API for XML Messaging Java API for XML Processing Java API for XML based RPC Java API for Web Services Java bindings of the General Security Services API Java Messaging Service Java Runtime Environment JavaService Faces JavaScript Object Notation JavaService Pages Java Secure Socket Extension Java Virtual Machine Lightweight Directory Access Protocol Lightweight Third Party Authentication Mandatory Access Control Multipurpose Internet Mail Extensions Microsoft Message Queuing Politechnika Poznańska 2010 10 11 24/26

MTOM OASIS OTP PAP PDP PEP PIB PKI RBAC REST RST RSTR SAAJ SACL SAML SAX SCT SCVP SMTP SOA SOAP SPML SSL SSO StAX STS TLS UDDI URI W3C WAS WS WSDL WSE WS I XACML XKMS XML XSLT Message Transmission Optimization Mechanism Organization for the Advancement of Structured Information Standards One Time Password Policy Administration Point Policy Decision Point Policy Enforcement Point Policy Information Base Public Key Infrastructure Role based Access Control REpresentational State Transfer Request Security Token Request Security Token Response SOAP with Attachments API for Java System Access Control List Security Assertion Markup Language Simple API for XML Security Context Token Simple Certificate Validation Protocol Simple Mail Transfer Protocol Service Oriented Architecture Simple Object Access Protocol, lately also Service Oriented Architecture Protocol Service Provisioning Markup Language Secure Socket Layer Single Sign On Streaming API for XML Security Token Service Transport Layer Security Universal Description, Discovery and Integration Uniform Resource Identifiers World Wide Web Consortium Windows Activation Service Web Services Web Services Description Language Web Services Enhancements Web Services Interoperability Organization extensible Access Markup Language XML Key Management Specification Extensible Markup Language Extensible Stylesheet Language Transformations Słowniczek audyt autentyczność autoryzacja brama rejestracja zdarzeń systemowych czy aplikacyjnych pewność co do pochodzenia (autorstwa i treści) danych proces przydzielania użytkownikowi praw dostępu do zasobów pośrednik (proxy), przez którego kierowane są zapytania usług internetowych Politechnika Poznańska 2010 10 11 25/26

delegacja przekazanie swoich uprawnień (np. klienta) innej jednostce deskryptor wdrożenia plik oparty na standardzie XML zawierający konfigurację bezpieczeństwa integralność ochrona informacji przed jej nieautoryzowanym zmodyfikowaniem interakcja wymiana wiadomości pomiędzy klientem a serwisem, związana z realizacją usługi interceptor / agent mechanizm przechwytywania komunikacji między uczestnikami interakcji, np. w celu wymuszenia stosowanie polityki kontekst interakcji zestaw informacji na temat jednostek interakcji, aspektów technicznych połączenia (infrastruktury) i zawartego kontraktu kontrakt wspólne uzgodnienia obu stron interakcji dotyczące nawiązywania połączenia kontrola dostępu procedura nadzorowania przestrzegania praw (dostępu do zasobów) log plik zawierający dane audytu niezaprzeczalność ochrona przed fałszywym zaprzeczeniem podmiot jednostka (użytkownik, aplikacja) ubiegająca się o dostęp do zasobu polityka bezpieczeństwa zbiór rozkazów i zakazów określający bezpieczne korzystanie z systemu poufność ochrona informacji przed jej nieautoryzowanym ujawnieniem prawa dostępu określają dopuszczalne sposoby wykorzystania zasobu przez podmiot przedmiot polityki zasób lub serwis serializacja zapis stanu obiektu w celu jego późniejszego odtworzenia serwis / usługa abstrakcyjna jednostka reprezentująca pewną funkcjonalność (lub zasoby) i komunikująca się poprzez wysyłanie i odbieranie wiadomości token bezpieczeństwa sformatowane pole nagłówka wiadomości dotyczące bezpieczeństwa uwierzytelnianie proces weryfikacji tożsamości podmiotu zarządca polityki kieruje konfiguracją polityk i ich cyklem życia zasób jednostka, do której dostęp podlega kontroli (np. pliki, programy, dane) Politechnika Poznańska 2010 10 11 26/26