Języki definiowania polityki bezpieczeństwa dla SOA

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 Doskonalenie narzędzi środowiska realizacji polityki bezpieczeństwa ORCA Bartosz Brodecki, Marek Chodorowski, Mateusz Falewicz, Adam Jodłowski, Katarzyna Kozłowska, Bartłomiej Kwiatkowski, Michał Rzepka, Piotr Sasak, Michał Szychowiak Sieć Naukowa Technologii Informacyjnych SOA

2 Informacje o dokumencie Numer raportu: Koordynator: Autorzy: Data: Poziom dostępności: Słowa kluczowe: Michał Szychowiak (PP) Bartosz Brodecki, Marek Chodorowski, Mateusz Falewicz, Adam Jodłowski, Katarzyna Kozłowska, Bartłomiej Kwiatkowski, Michał Rzepka, Piotr Sasak, Michał Szychowiak (PP) (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 /67

3 Historia zmian w dokumencie 1 Wersja Data modyfikacji Zmodyfikowane przez Opis modyfikacji Michał Szychowiak (PP) Utworzenie dokumentu, struktura treści Michał Szychowiak (PP) p. 4.4 Asercje kontraktu bezpieczeństwa Michał Szychowiak (PP) p. 4.3 Negocjacja kontraktów bezpieczeństwa poprzez PDP Michał Szychowiak (PP) c.d. p Piotr Sasak(PP) asercje SAMLowe dla wiadomości: ORCA_RESP register_interaction Michał Szychowiak (PP) p. 4.1 Uwierzytelnianie stron interakcji Piotr Sasak (PP) Dodałem asercje potwierdzającą uwierzytelnienie podmiotu w pkt Michał Szychowiak (PP) Poprawki kosmetyczne Michał Szychowiak (PP) Wersja sprawozdawcza Michał Szychowiak (PP) Uzupełnienie opisu wymagań dla aplikacji REST o przekazywanie nie tylko Originatora, ale również Invokera (Listing 6 i Listing 7) Marek Chodorowski (PP) Instalacja certyfikatów x509 w WCF Marek Chodorowski (PP) Kolejność przetwarzania nagłówków w PEP Marek Chodorowski (PP) Zabezpieczanie komunikacji między PDP a PEP Michał Szychowiak (PP) Obsługa X.509 w PDP (punkt 4.6) Marek Chodorowski Zarządzanie kluczami w WCF Marek Chodorowski Zabezpieczanie komunikacji między modułami PEP Michał Szychowiak (PP) Poprawki asercji SAML Listing 23 1 Tylko do użytku wewnętrznego Politechnika Poznańska /67

4 Spis treści Streszczenie Wstęp... 6 Cel i zakres raportu... 7 Struktura raportu Model architektury środowiska ORCA Docelowa architektura środowiska ORCA Ewolucja prototypowej architektury środowiska ORCA Dualne interfejsy usługi PDP Doskonalenie narzędzi środowiska ORCA Uwierzytelnianie stron interakcji Ochrona komunikacji w środowisku ORCA Uwierzytelnianie komponentów środowiska ORCA Interakcja PEP PDP Interakcja PDP PIB Negocjacja kontraktów bezpieczeństwa poprzez PDP Przyczyny Zmodyfikowany protokół PEP PDP Optymalizacja Asercje kontraktu bezpieczeństwa Asercje uwierzytelniania Weryfikacja certyfikatów X Modyfikacje modułu PEP w WCF Instalacja certyfikatów x509 w WCF Zarządzanie nagłówkami dodawanymi przez PEP Implementacja modułów odpowiedzialnych za podpisywanie i szyfrowanie wiadomości Inne usprawnienia Wykorzystane technologie i narzędzia Moduł PEP dla środowiska WebSphere Moduł PEP dla środowiska WCF Moduły PDP/PIB/PIP/PAL Scenariusze weryfikacji funkcjonalnej środowiska ORCA Scenariusz F.1: uwierzytelnianie interakcji Scenariusz F.2: autoryzacja interakcji bez zagnieżdżenia Scenariusz F.3: autoryzacja poprzez delegację Scenariusz F.4: uzgodnienie kontraktu bezpieczeństwa Scenariusz F.5: audyt Scenariusz F.6: predykaty warunkowe Podsumowanie Bibliografia Wykaz skrótów i słowniczek pojęć Politechnika Poznańska /67

5 Streszczenie Niniejszy raport przedstawia wyniki prac badawczych i implementacyjnych prowadzonych nad rozwojem prototypu środowiska ORCA i doskonaleniem narzędzi środowiska. Prace te stanowią jeden z elementów realizacji zadania OB7-5: Języki definiowania polityki bezpieczeństwa dla SOA w Etapie 3 Fazy 1 (okres styczeńczerwiec 2010 r.) prac obszaru OB7: Zarządzanie środowiskiem i aplikacjami SOA projektu ITSOA. Raport omawia rozszerzenie prototypowej architektury środowiska ORCA w kierunku architektury docelowej oraz modyfikację protokołów środowiska mającą na celu rozszerzenie funkcjonalności środowiska z uwzględnieniem wyników weryfikacji i ewaluacji wersji eksperymentalnej środowiska zrealizowanej w poprzednim etapie prac. Politechnika Poznańska /67

6 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 [12] 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 [15], a komunikacja odbywa się poprzez protokół SOAP [16] bazujący na składni XML [13], 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 [18]). 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 /67

7 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 [8], zatem niezbędne jest zaproponowanie nowego języka. W pracy [5] zaproponowano taki język oraz architekturę środowiska realizacji polityki. Dokonano również prototypowej implementacji tego środowiska o uproszczonej architekturze [6],[7]. Niniejszy raport omawia rozszerzenie prototypowej architektury środowiska ORCA w kierunku architektury docelowej oraz modyfikację protokołów środowiska mającą na celu rozszerzenie funkcjonalności środowiska z uwzględnieniem wyników weryfikacji i ewaluacji wersji eksperymentalnej środowiska zrealizowanej w poprzednim etapie prac. 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 jest następująca. W rozdziale 2 pokrótce przedstawiono model środowiska ORCA. W kolejnych rozdziałach przedstawiono wyniki prac implementacyjnych nad udoskonaleniem prototypowej implementacji środowiska. I tak, rozdział 3 opisuje udoskonalenie architektury prototypu środowiska, a rozdział 4 udoskonalenie protokołów interakcji między komponentami środowiska. Rozdział 6 przedstawia scenariusze badawcze weryfikacji funkcjonalnej środowiska. Ostatecznie, rozdział 7 zawiera krótkie podsumowanie prac. Politechnika Poznańska /67

8 2. Model architektury środowiska ORCA W celu umożliwienia definiowania i przetwarzania polityki bezpieczeństwa należy wprowadzić pewien model funkcjonalny, dostosowany do specyfiki SOA. Fundamentalne jednostki tego modelu to: przedmiot polityki np. serwis lub zasób podmiot polityki np. klient uzyskujący dostęp do przedmiotu polityki reguły polityki definiujące wymagania dotyczące zabezpieczeń zastosowane wobec podmiotu. mechanizmy egzekwowania polityki bezpieczeństwa. Rozróżnienie tych podstawowych elementów związanych z polityką bezpieczeństwa pozwala na efektywne oddzielenie samych danych polityki od jej implementacji. 2.1 Docelowa architektura środowiska ORCA W tym punkcie przedstawiona zostanie architektura środowiska ORCA [5]. Rysunek 1 przedstawia graficznie tę architekturę, uwzględniając przepływ danych pomiędzy komponentami odpowiedzialnymi za definicję i realizację reguł polityki. Nazwy jednostek widoczne na rysunku oznaczają: PAP (ang. Policy Administration Point) wykorzystywany jest do zdefiniowania reguł dostępu do zasobów, PIB (ang. Policy Information Base) zawiera zasady określone przez PAP, PDP (ang. Policy Decision Point), podejmuje decyzje o zatwierdzeniu żądania dostępu do zasobu w oparciu o reguły zawarte w PIB, PEP (ang. 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. PIP (ang. Policy Information Point) dostarcza w bieżącej domenie wszystkich informacji nieobecnych w lokalnym PIB i związanych z interakcjami międzydomenowymi, np. w obrębie domen sfederowanych w wirtualnej organizacji, PAL (ang. Policy Audit Log) rejestrator zdarzeń dotyczących bezpieczeństwa interakcji, PDP cache replikowana pamięć podręczna decyzji PDP usprawniająca efektywność realizacji rozproszonej polityki SOA. Rdzeniem tego modelu jest współpraca PDP (który decyduje o kontroli dostępu na podstawie reguł polityki) z PEP (który przechwytuje żądania dostępu do usługi S Politechnika Poznańska /67

9 składane przez klientów i egzekwuje decyzje PDP, dopuszczając lub odmawiając żądanego dostępu). Typowo przyjmuje się, że w przypadku gdy z powodu braku odpowiednich reguł zawartych w PIB jednostka PDP nie potrafi podjąć decyzji o autoryzacji dostępu do zasobów, może zamiast tego zwrócić informację o błędzie. PIP PEP PAP PIB PAL PDP PDP cache PDP cache PEP PEP C S Rysunek 1. Architektura środowiska ORCA Istotną cechą środowiska ORCA jest fakt, że komponenty PDP, PIB, PIP i PAL są usługami. Stąd też interakcje z tymi komponentami same mogą podlegać regułom polityki SOA. I tak przykładowo, rolę klientów usługi PDP pełnią oczywiście moduły PEP, dowiązane do dostawców usług (S) i aplikacji klienckich (C). Sposób owego dowiązania jest zależny od konkretnej platformy aplikacyjnej i musi umożliwiać takie obudowanie aplikacji, aby nie mogła ona realizować w systemie SOA komunikacji z pomięciem pośrednictwa PEP. Moduły PEP w środowisku ORCA nie tylko egzekwują decyzje kontroli dostępu do usług, ale pobierają i realizują zdefiniowane dla podmiotów (zarówno S, jaki i C) Obligations i Capabilities. One również zajmują się realizacją kontrolowanej przez politykę delegacji uprawnień w przypadku zagnieżdżenia usług. Podobnie, moduł PIB (pełniący rolę repozytorium reguł polityki) jest w środowisku ORCA usługą, z której korzystają PDP (do pozyskiwania reguł polityki pasujących do kontekstu żądania dostępu zgłoszonego przez PEP, w tym nie tylko reguł Restrictions ale również Obligations, Capabilities i Audit). Natomiast moduł PAP jest aplikacją kliencką do edycji reguł polityki bezpieczeństwa, wzbogaconą o mechanizmy weryfikacji poprawności polityki. Architekturę wewnętrzną modułu 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 /67

10 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 [20]) 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 Politechnika Poznańska /67

11 (z wiadomości wydobywane są atrybuty podmiotów, a ze środowiska 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). 3. Ewolucja prototypowej architektury środowiska ORCA W ramach wcześniejszego Etapu 2 Fazy 1 opracowano i zrealizowano prototyp środowiska ORCA o uproszczonej architekturze i wybranym podzbiorze funkcjonalności [6], [7]. Celem realizacji tego prototypu było umożliwienie przeprowadzenia eksperymentalnej weryfikacji koncepcji środowiska i działania prototypowych wersji narzędzi w systemie przetwarzania zorientowanego na usługi. Architekturę prototypu przedstawia Rysunek 3. Raport [7] opisuje prototypowe wersje narzędzi PAP, PIB i PDP. Natomiast raport [6] przedstawia implementację i konfigurację modułów PEP dla wybranych platform aplikacyjnych wraz z protokołem PEP PDP. Politechnika Poznańska /67

12 PAP PIB repository PDP C PEP PEP S 3.1 Dualne interfejsy usługi PDP Rysunek 3. Architektura prototypowej implementacji (z Etapu 2) Ze względu na dużą częstotliwość i skomplikowaną naturę zapytań kierowanych przez PDP do repozytorium polityki zdecydowano o rezygnacji z kosztownego protokołu PDP PIB i połączeniu usługi PDP z PIB w jeden moduł implementujący interfejsy obu tych usług (Rysunek 4). Zatem z perspektywy PAP moduł ten zachowuje się jak PIB, natomiast z perspektywy PEP jak PDP. PAP PIB PDP policy PEP S Rysunek 4. Architektura scalonego modułu PDP-PIB Politechnika Poznańska /67

13 4. Doskonalenie narzędzi środowiska ORCA 4.1 Uwierzytelnianie stron interakcji Interceptor PEP po stronie wywoływanej usługi przepuści wywołanie bądź nie, na podstawie decyzji uzyskanej od usługi PDP (Policy Decision Point) operującej na danych uwierzytelniających (ang. credentials) przekazywanych od interceptora PEP klienta, być może niezależnie od świadomości procesów samych aplikacyjnych. Jeśli jednak uwierzytelnianie użytkownika jest dokonywane przez aplikację kliencką i dane te są przesyłane do usługi w wiadomości aplikacyjnej (żądaniu), np. w tokenie WS-Security (dla SOAP) lub w polu Authorization: nagłówka HTPP (dla usług REST). W takim przypadku PEP potrafi wykorzystać te dane, o ile zostanie mu wskazana ich lokalizacja w wiadomości. Wskazanie lokalizacji następuje w pliku konfiguracyjnym interceptora PEP klienta: dla SOAP: <?xml version="1.0" encoding="iso "?> <ConfigStructure> <PDP_uri> <PDP_name>Esculap_ORCA_PDP</PDP_name> <PEP_name> Esculap_ORCA_PEP</PEP_name> <Principal> <PrincipalName> <PrincipalCredentials> <UsernameToken>Header/Security/UsernameToken</UsernameToken> <Certificate>Header/Security/Signature/KeyInfo/SecurityToken Reference/KeyIdentifier/@ValueType</Certificate> </PrincipalCredentials> </Principal> </ConfigStructure> Listing 1. Plik konfiguracyjny PEP obsługującego protokół SOAP Zgodnie z powyższym przykładem, PEP będzie oczekiwał, iż dane uwierzytelniające są przekazywane w żądaniu aplikacyjnym w tokenie uwierzytelniania UsernameToken (nazewnictwo zgodne ze standardem WS-Security) w nagłówku protokołu SOAP: Politechnika Poznańska /67

14 <header>... <security> <UsernameToken> <username>jbond</username> <password>walther9mm</password> </UsernameToken> </security>... </header> Listing 2. Nagłówek <security> w żądaniu SOAP z tokenem uwierzytelniania dla REST: <?xml version="1.0" encoding="iso "?> <ConfigStructure> <PDP_uri> <PDP_name>Esculap_ORCA_PDP</PDP_name> <PEP_name> Esculap_ORCA_PEP</PEP_name> <Principal> <PrincipalName> <PrincipalCredentials> <UsernameToken>Authorization:</UsernameToken> <Certificate>Authorization:</Certificate> </PrincipalCredentials> </Principal> </ConfigStructure> Listing 3. Plik konfiguracyjny PEP obsługującego protokół HTTP W przypadku powyższego przykładu dla REST, PEP będzie oczekiwał, iż dane uwierzytelniające dla usługi są przekazywane w żądaniu aplikacyjnym w tokenie uwierzytelniania w polu Authorization nagłówka HTTP (nazewnictwo zgodne ze standardem HTTP Basic Authentication):... Authorization: Basic cghvdg9hchaumdaxomjhc2ljyxv0aa==... Listing 4. Fragment nagłówka HTTP z polem Authorization Ponadto oczekiwane jest wskazanie w wiadomości aplikacyjnej wychodzącej od klienta (inicjującego sesję) tożsamości podmiotu (użytkownika Originator) i/lub tożsamości aplikacji (Invoker), jeśli ma ona być wykorzystywana do uwierzytelnienia wywołania usługi: dla SOAP: <header>... <message> Politechnika Poznańska /67

15 ... <originator id= JBond /> <invoker id= client1 />... </message>... </header> Listing 5. Fragment nagłówka <message> wiadomości SOAP z polem Originator oraz Invoker dla REST:... X-Originator-ID: JBond X-Invoker-ID: client1... Listing 6. Fragment nagłówka HTTP z polem Originator oraz Invoker oraz roli podmiotu, jeśli autoryzacja obywa się z wykorzystaniem ról (zgodnie z modelem Role-Based Access Control): dla SOAP: <header>... <message>... <role= Secret Agent />... </message>... </header> dla REST: Listing 7. Fragment nagłówka <message> wiadomości SOAP z polem Role... X-Role: Secret Agent... Listing 8. Fragment nagłówka HTTP z polem Role Usługa jest zawsze zobowiązana do przekazywania swojej tożsamości w wychodzących wywołaniach: Politechnika Poznańska /67

16 dla SOAP: <header>... <message>... <invoker id= service1 />... </message>... </header> Listing 9. Fragment nagłówka <message> wiadomości SOAP wychodzącej z usługi dla REST:... X-Invoker-ID: service1... Listing 10. Fragment nagłówka HTTP wychodzącej z usługi 4.2 Ochrona komunikacji w środowisku ORCA Uwierzytelnianie komponentów środowiska ORCA Wszystkie komponenty środowiska ORCA są uwierzytelniane przy pomocy certyfikatów X.509 wystawianych przez Urząd Certyfikujący (CA) zaufany przez PDP w lokalnej domenie. Wystawione przez ten urząd certyfikaty oraz certyfikat samego urzędu (dokł. RootCA) muszą być przechowywane w dostępnym dla danego komponentu repozytorium kluczy, np. w lokalnym truststore lub keystore (można wykorzystać standardowy trustore maszyny wirtualnej Java wykonującej kod komponentu. Nazwa domeny oraz nazwy podmiotów identyfikujące właściwe certyfikaty (Common Name) muszą być zdefiniowane w pliku konfiguracyjnym komponentu. Listing 11 pokazuje przykład pliku konfiguracyjnego PEP, w którym wskazane są Common Name bieżącego modułu PEP (<PEP_name>), jego PDP (<PDP_name>) oraz PAL (<PAL_name>). Listing 11. Plik konfiguracyjny PEP <?xml version="1.0" encoding="iso "?> <ConfigStructure> <DomainID>ORCA_realm1</DomainID> <PEP_name>ORCA_PEP1</PEP_name> <PDP_name>ORCA_PDP1</PDP_name> <PDP_uri> <PAL_name>ORCA_PAL1</PAL_name> <Principal> <PrincipalName> <PrincipalCredentials> <UsernameToken>Header/Security/UsernameToken</UsernameToken> Politechnika Poznańska /67

17 <Certificate>Header/Security/Signature/KeyInfo/SecurityToken </PrincipalCredentials> </Principal> </ConfigStructure> Podobnie, nazwy Common Name kontaktujących się ze sobą komponentów możemy znaleźć w kolejnych przykładach: Listing 12 i Listing 13. Listing 12. Plik konfiguracyjny PDP <?xml version="1.0" encoding="iso "?> <ConfigStructure> <DomainID>ORCA_test_realm</DomainID> <PDP_name>ORCA_PDP1</PDP_name> <PIP_uri> <PIP_name>ORCA_PIP1</PIP_name> </ConfigStructure> Listing 13. Plik konfiguracyjny PAP <?xml version="1.0" encoding="iso "?> <ConfigStructure> <PAL_name>ORCA_PAL1</PAL_name> <PIB_uri> <PDP_name>ORCA_PDP1</PDP_name> </ConfigStructure> Moduły PEP przekazują swoje nazwy Common Name do PDP w momencie rejestracji (ORCA_REQ register_subject / register_target). Nazwy muszą zostać wymienione między stronami uczestniczącymi w interakcji, aby zapewnić obopólną możliwość zabezpieczenia kryptograficznego komunikatów aplikacyjnych (SOAP_REQ / SOAP_RESP). Wymiana następuje za pośrednictwem PDP, w komunikacie ORCA_RESP register_interaction szerzej omówionym w pkt Pokazuje to Listing 14. Listing 14. ORCA_RESP register_interaction message <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE orca_register_interaction_resp SYSTEM "orca_register_interaction_resp.dtd"> <orca_register_interaction_resp> <target id=" <target_attributename="commonname"> ORCA_PEP1</target_attribute> </target> <subjects> <subject id="clientapp1"> <subject_attribute name="commonname"> ORCA_PEP2</subject_attribute> </subject> </subjects> </orca_register_interaction_resp> Politechnika Poznańska /67

18 Interakcja PEP PDP Proces modyfikacji protokołu PEP-PDP wynikający z optymalizacji interakcji środowiska ORCA został omówiony w p Tam też znajduje się specyfikacja aktualnego formatu protokołu. Interakcja PDP PIB Z powodu połączenia usług PDP i PIB w jeden moduł, protokół PDP PIB nie będzie implementowany w bieżącej wersji środowiska ORCA. 4.3 Negocjacja kontraktów bezpieczeństwa poprzez PDP Przyczyny Przez kontrakt bezpieczeństwa rozumiany jest zbiór parametrów opisujących zabezpieczenia interakcji (w innych obszarach stosowane jest niekiedy analogiczne pojęcie asocjacji bezpieczeństwa). W środowisku ORCA, zbiór ten obejmuje elementy specyfikowane w polityce bezpieczeństwa w postaci reguł Obligations i Capabilities. Na podstawie tych reguł, kontrakt bezpieczeństwa ustanawiany jest (w formie negocjacji) przez faktycznym rozpoczęciem interakcji. Pierwotnie, projekt środowiska ORCA przewidywał autonomiczne i transparentne dla końcowych stron interakcji negocjowanie kontraktu bezpieczeństwa przez ich moduły PEP w momencie pojawienia się wywołania (ang. invocation) po stronie inicjującej interakcję (tj. stronie klienta). Jednak w przypadku interakcji realizowanych zgodnie z modelem WS (Web Services), z powodów wymienionych poniżej, podejście to okazało się trudne do realizacji i niepraktyczne. Prototypowa implementacja środowiska ORCA dostosowana jest do kontroli interakcji realizowanych zgodnie z modelem WS, przy wykorzystaniu protokołu SOAP i definicji interfejsu w języku WSDL. Jest to aktualnie zdecydowanie najpopularniejszy przypadek, spośród spotykanych na rynku rozwiązań zgodnych z paradygmatem SOA. Wiele platform aplikacyjnych, wśród nich również te uwzględnione w implementacji środowiska ORCA, oferuje ułatwienia w konstrukcji aplikacji i realizacji interakcji zgodnych z modelem WS. Przykładowo, identyfikacja usługi (jako strony interakcji) dokonywana jest poprzez tzw. punkt końcowy (ang. endpoint) dowiązany do interfejsu usługi. Ponieważ zadaniem modułu PEP jest transparentne pośredniczenie w komunikacji między stronami interakcji, nie posiada on żadnego widocznego punktu końcowego. Komunikacja przepływa przez PEP w sposób niemożliwy do obejścia i jednocześnie całkowicie niewidoczny dla żadnej ze stron (oczywiście dzięki odpowiedniemu wsparciu platformy aplikacyjnej). W konsekwencji jednak, nie ma prostej możliwości realizacji bezpośredniej komunikacji pomiędzy samymi modułami PEP dwóch stron interakcji (tzn. takiej komunikacji, w której oba moduły są punktami Politechnika Poznańska /67

19 docelowymi). Niestety, uniemożliwia to autonomiczną negocjację kontraktu bezpieczeństwa przez same moduły PEP. Rozważając alternatywne sposoby negocjacji, podjęto ostatecznie decyzję o włączeniu pośrednictwa PDP w proces negocjacji kontraktu bezpieczeństwa. Moduł PDP, mając dostęp do reguł polityki bezpieczeństwa, jest naturalnie predestynowany do efektywnego autorytatywnego ustalenia kontraktu, bez potrzeby faktycznej wymiany komunikatów pomiędzy zainteresowanymi modułami PEP. Zaletą tego podejścia jest również możliwość dalszego uproszczenia procedury negocjacji (optymalizacji) poprzez dokonanie jej jednostronnie (po stronie klienta) i przekazanie jej efektu stronie drugiej w samym komunikacie wywołania usługi. Poniżej przedstawiono opis protokołu ORCA_PEP-PDP, w ramach którego odbywa się negocjacja kontraktu bezpieczeństwa, najpierw bez wspomnianej optymalizacji, a następnie wraz z nią. Zmodyfikowany protokół PEP PDP Negocjacja kontraktu bezpieczeństwa dokonuje się w ramach interakcji PEP z usługą PDP, w czasie zgłoszenia wywołania usługi docelowej (S1) przez klienta (C). Interakcję PEP PDP opisuje protokół ORCA_PEP-PDP. Listing 15 przedstawia schemat wymiany komunikatów tego protokołu. Symbole PEP S1 i PEP C oznaczają odpowiednio moduł PEP strony usługi oraz strony klienta. W schemacie na listingu rozważane jest dodatkowo zagnieżdżone wywołanie usługi S2 przez S1. Szczegółowy opis protokołu znajduje się w raporcie [5]. W linii 5 listingu przedstawione jest wychodzące z aplikacji klienta C wywołanie usługi S1, które nie należy do protokołu ORCA_PEP-PDP. W wyniku jednak tego zdarzenia moduł PEP C reaguje rejestrując w PDP interakcję C z S1 (komunikat ORCA_REQ register_interaction w linii 6). PDP dokonuje ustalenia kontraktu i odsyła w odpowiedzi ustalone wymagania kontraktu clientobligations dla strony klienta (linia 7). Analogiczne operacje występują przy zagnieżdżonej interakcji S1 z S2 (linie 12 i 13). Występuje jednak różnica między rejestracją interakcji dla pierwszego klienta (czyli tam gdzie znajduje się Originator bieżącej sesji), gdzie mianowicie rejestracji poddawana jest tożsamość i podmiotu Originator i podmiotu Invoker (mogą występować oba podmioty, oczywiście różne) linia 6, a rejestracją interakcji dalej w sesji, gdzie jedynym nowym podmiotem jest kolejny Invoker linia 12. PDP właściwy dla domeny usługi ustala i przekazuje jej serviceobligations wraz z decyzją kontroli dostępu (w komunikacie ORCA_RESP policy_decision linia 10). Negocjację pośrednią przedstawia schematycznie Rysunek 5. Numery strzałek na rysunku odpowiadają krokom protokołu, które przedstawia Listing 15. Politechnika Poznańska /67

20 PDP Client PEP 11 PEP Service Rysunek 5. Schemat pośredniej negocjacji PEP PDP PEP Listing 15. Schemat interakcji PEP PDP w przypadku pośredniej negocjacji kontraktu preparation for audit 1. PEP S1 PDP: ORCA_REQ register_target (Service) 2. PEP S1 PDP: ORCA_RESP register_target (Service, Audit) 3. PEP C PDP: ORCA_REQ register_subject (Client) 4. PEP C PDP: ORCA_RESP register_subject (Client, Audit) request processing 5. Client : SOAP_REQ (Session, Originator, Invoker, Target, Action, subject_attributes) 6. PEP C PDP: ORCA_REQ register_interaction (Originator, Invoker, Target) 7. PEP C PDP: ORCA_RESP register_interaction(clientobligations) 8. Service S1: SOAP_REQ (Session, Originator, Invoker, Subjects, Target, Action, subject_attributes) 9. PEP S1 PDP: ORCA_REQ policy_decision (Subjects, Target, Action, subject_attributes, target_attributes) 10. PEP S1 PDP: ORCA_RESP policy_decision (Decision, serviceobligations) nested interaction 11. S1 : SOAP_REQ (Session, Invoker, Target, Action, subject_attributes) 12. PEP s1 PDP: ORCA_REQ register_interaction (Originator, Invoker, Target) 13. PEP s1 PDP: ORCA_RESP register_interaction (clientobligations) 14. Service S2: SOAP_REQ (Session, Originator, Invoker, Subjects, Target, Action, subject_attributes) 15. PEP S2 PDP: ORCA_REQ policy_decision (Subjects, Target, Action, subject_attributes, target_attributes) 16. PEP S2 PDP: ORCA_RESP policy_decision (Decision, serviceobligations) 17. S1 S2: SOAP_RESP (Target) end of nested interaction 18. Client S1: SOAP_RESP (Target) Optymalizacja W celu uniknięcia dwukrotnego ustalania kontraktu bezpieczeństwa tej samej interakcji, tj. raz po stronie klienta, a drugi po stronie usługi, zaproponowano dalsze Politechnika Poznańska /67

21 usprawnienie omawianego protokołu. W wyniku tego usprawnienia, PDP strony klienta ustala od razu obie części kontraktu zarówno clientobligations, jak i serviceobligations. Dalej, serviceobligations przekazywane są do strony usługi w komunikacie wywołania usługi (odpowiednik kroków 8 i 14 na poprzednim listingu), tj. w żądaniu aplikacyjnym SOAP REQ, w nagłówku <orca>. Schematycznie przedstawia tę optymalizację Rysunek 6. PDP C PEP 11 PEP S1 Rysunek 6. Optymalizacja pośredniej negocjacji PEP PDP PEP Autentyczność i integralność obu części kontraktu bezpieczeństwa (zwłaszcza części serviceobligations istotnej dla usługi, która w tym przypadku w żadnej formie nie uczestniczy aktywnie w negocjacji) można (w istocie należy) zagwarantować w formie asercji podpisywanej przez wystawiający ją PDP strony klienta (zatem musi on być zaufany w domenie usługi, np. w efekcie kontraktu między-domenowego Wirtualnej Organizacji). Asercje kontraktu bezpieczeństwa omawia punkt 4.4. Opracowana optymalizacja zapewnia dodatkowo spójność negocjacji obu części kontraktu bezpieczeństwa pod względem wykorzystanej wersji polityki. Dokonanie negocjacji obu części w jednym miejscu czasie wyklucza zmianę wersji polityki pomiędzy uzgodnieniem elementu clientobligations a ustaleniem serviceobligations, co schematycznie obrazuje analiza zaprezentowana na poniższych rysunkach. Rysunek 7 przedstawia wariant pośredniej negocjacji kontraktu bezpieczeństwa, który został wcześniej omówiony (Rysunek 5 i Listing 15), a który nie gwarantuje spójności procesu negocjacji. Natomiast Rysunek 8 odpowiada wariantowi zoptymalizowanemu, który spójność negocjacji zachowuje. Politechnika Poznańska /67

22 rev_num=4 policy PIB PDP rev_num=5 fetch O/C for Client fetch O/C for Service PEP C PEP S Client Service Rysunek 7. Wariant bez spójności negocjacji policy rev_num=4 PIB PDP fetch O/C for Client and Service PEP C PEP S Client Service Rysunek 8. Wariant zachowujący spójność negocjacji Poniższe listingi przedstawiają zmodyfikowany protokół PEP PDP dla wersji zoptymalizowanej pośredniej negocjacji kontraktu bezpieczeństwa. Listing 16. Schemat interakcji PEP PDP zoptymalizowanej pośredniej negocjacji preparation for audit 1. PEP S1 PDP: ORCA_REQ register_target (Service) 2. PEP S1 PDP: ORCA_RESP register_target (Service, Audit) 3. PEP C PDP: ORCA_REQ register_subject (Client) 4. PEP C PDP: ORCA_RESP register_subject (Client, Audit) request processing Politechnika Poznańska /67

23 5. Client : SOAP_REQ (Session, Originator, Invoker, Target, Action, subject_attributes) 6. PEP C PDP: ORCA_REQ register_interaction (Originator, Invoker, Target) 7. PEP C PDP: ORCA_RESP register_interaction(oblig C, Oblig S1 ) 8. Service S1: SOAP_REQ (Session, Originator, Invoker, Subjects, Target, Action, subject_attributes, Oblig S1 ) 9. PEP S1 PDP: ORCA_REQ policy_decision (Subjects, Target, Action, subject_attributes, target_attributes) 10. PEP S1 PDP: ORCA_RESP policy_decision (Decision) nested interaction 11. S1 : SOAP_REQ (Session, Invoker, Target, Action, subject_attributes) 12. PEP s1 PDP: ORCA_REQ register_interaction (Originator, Invoker, Target) 13. PEP s1 PDP: ORCA_RESP register_interaction (Oblig C, Oblig S2 ) 14. Service S2: SOAP_REQ (Session, Originator, Invoker, Subjects, Target, Action, subject_attributes, Oblig S2 ) 15. PEP S2 PDP: ORCA_REQ policy_decision (Subjects, Target, Action, subject_attributes, target_attributes) 16. PEP S2 PDP: ORCA_RESP policy_decision (Decision) 17. S1 S2: SOAP_RESP (Target) end of nested interaction 18. Client S1: SOAP_RESP (Target) Format odpowiedzi ORCA_RESP register_interaction zoptymalizowanego protokołu PEP PDP przedstawia Listing 17 (wiadomość ta jest przekazywana w kroku 7 oraz 13 interakcji, której schemat przedstawia Listing 16). Listing 17. ORCA_RESP register_interaction message <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE orca_register_interaction_resp SYSTEM "orca_register_interaction_resp.dtd"> <orca_register_interaction_resp> <obligations> <obligation_token> <subject id= JBond > <action> authenticate </action> <method> X.509certificate </method> </obligation_token> <obligation_token> <subject id= JBond > <action> encrypt </action> <method> xmlenc#aes128-cbc </method> </obligation_token> Politechnika Poznańska /67

24 <obligation_token> <subject id= C > <action> authenticate </action> <method> X.509certificate </method> </obligation_token> </obligation_token> <obligation_token> <subject id= C > <action> sign </action> <method> xmlsig#hmac-sha1 </method> </obligation_token> <obligation_token> <target id= > <action> sign </action> <method> xmlsig#hmac-sha1 </method> </obligation_token> <obligation_token> <target id= > <action> encrypt </action> <method> xmlenc#aes128-cbc </method> </obligation_token> </obligations> </orca_register_interaction_resp> Element kontraktu serviceobligations jest przekazywany między modułami PEP klienta i usługi w nagłówku SOAP wywołania usługi (wiadomość przekazywana w kroku 8 oraz 14 interakcji, której schemat przedstawia Listing 16), co prezentuje Listing 18. Listing 18. SOAP_REQ message containing target-side obligation tokens <soap> <header> <orca> <obligation_token> <target id= > Politechnika Poznańska /67

25 <action> sign </action> <method> xmlsig#hmac-sha1 </method> </obligation_token> <obligation_token> <target id= > <action> encrypt </action> <method> xmlenc#aes128-cbc </method> </obligation_token> </orca> </header> </soap> W przypadku braku wymagań (pusty kontrakt bezpieczeństwa) odpowiedź ORCA_RESP register_interaction przyjmuje postać, którą prezentuje Listing 19. Listing 19. ORCA_RESP register_interaction message for no obligations <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE orca_register_interaction_resp SYSTEM "orca_register_interaction_resp.dtd"> <orca_register_interaction_resp> <obligations> <obligation_token> <subject id= C > <action/> <method/> </obligation_token> <obligation_token> <target id= > <action/> <method/> </obligation_token> </obligations> </orca_register_interaction_resp> W przypadku niemożliwości uzgodnienia kontraktu bezpieczeństwa (negocjacja prowadzi do wykrycia konfliktu odpowiadających sobie wzajemnie reguł Obligations i Capabiblities) odpowiedź ORCA_RESP register_interaction przyjmuje postać, którą prezentuje Listing 20. Listing 20. ORCA_RESP register_interaction message for unsuccessful contract negotiation <?xml version="1.0" encoding="utf-8"?> Politechnika Poznańska /67

26 <!DOCTYPE orca_register_interaction_resp SYSTEM "orca_register_interaction_resp.dtd"> <orca_register_interaction_resp> <obligations> <obligation_token> <action> indeterminate </action> <method/> </obligation_token> </obligations> </orca_register_interaction_resp> 4.4 Asercje kontraktu bezpieczeństwa W celu minimalizacji narzutu komunikacyjnego na proces pośredniej negocjacji kontraktu bezpieczeństwa, zaimplementowano mechanizm ustalania i publikowania przez PDP asercji kontraktu. Asercja obejmuje ustalone przez PDP (zatem pośrednio wynegocjowane) obopólne Obligations: parametry szyfrowania żądania parametry podpisywania żądania parametry szyfrowania odpowiedzi parametry podpisywania odpowiedzi clientobligations serviceobligations Asercja ta skierowana jest dla docelowej strony interakcji (PEP wywoływanego serwisu) lecz jest przekazywana do strony źródłowej (PEP klienta bieżącej interakcji) w komunikacie ORCA_RESP register_interaction. Dalej, moduł PEP klienta, jako pośrednik, przekazuje asercję do modułu PEP zainteresowanego serwisu w żądaniu aplikacyjnym (SOAP REQ), w nagłówku <orca>. Asercja jest zbudowana w formacie SAML i jest podpisywana cyfrowo przez wystawcę, tj. PDP. Po stronie wywoływanego serwisu, moduł PEP: 1. weryfikuje podpis PDP i akceptuje asercję; 2. weryfikuje zgodność zaaplikowanych przez źródłowy PEP zabezpieczeń żądania SOAP REQ z otrzymaną asercją; 3. weryfikuje zgodność zastosowania przez źródło metody uwierzytelniania żądania (wyznaczonej na podstawie typu danych uwierzytelniających przekazanych w nagłówku <orca> żądania) z Obligations pozyskanymi wcześniej (i buforowanymi w pamięci podręcznej Obl_cache) od PDP w komunikacie ORCA_RESP register_target. 4. występuje o decyzję PDP odnośnie kontroli dostępu i aplikuje ją 5. w momencie przekazywana zwrotnie odpowiedzi SOAP RESP, aplikuje Obligations Każdy z kolejnych kroków powyższego schematu postępowania wykonywany jest jedynie w przypadku pomyślnego zakończenia korku wcześniejszego. Politechnika Poznańska /67

27 Listing 21 przedstawia asercje zapisane w języku SAML w wiadomości: ORCA_RESP register_interaction. Politechnika Poznańska /67

28 Listing 21. Przykładowe asercje w języku SAML <saml:assertion xmlns:saml= urn:oasis:names:tc:saml:2.0:assertion Version="2.0" IssueInstant=" T12:00:00Z" ID="_a75adf55"> <saml:issuer Format=urn:oasis:names:SAML:2.0:nameid-format:entity> </saml:issuer> <ds:signature xmlns:ds=" <ds:signedinfo> <ds:canonicalizationmethod Algorithm=" <ds:signaturemethod Algorithm=" <ds:reference URI="#_a75adf55"> <ds:transforms> <ds:transform Algorithm=" <ds:transform Algorithm=" <InclusiveNamespaces PrefixList="#default saml ds xs xsi orca" xmlns=" </ds:transform> </ds:transforms> <ds:digestmethod Algorithm=" <ds:digestvalue> Kclet6XcaOgOWXM4gty6/UNdviI= </ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue> hq4zk+zknjggcqgzm7ea8fi7...hr7whxvccrwubfz6rqvl+wnmewi4= </ds:signaturevalue> <ds:keyinfo> <ds:x509data> <ds:x509certificate> MRIwEAYDVQQIEwlXaXNjb...6Hr7wHxdfrvCCRwubnZAv2FU78p== </ds:x509certificate> </ds:x509data> </ds:keyinfo> </ds:signature> <saml:subject> Politechnika Poznańska /67

29 <saml:nameid Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"> JBond </saml:nameid> </saml:subject> <saml:authnstatement AuthnInstant=" T12:00:00Z" SessionIndex=" "> <saml:authncontext> <saml:authncontextclassref> urn:oasis:names:tc:saml:2.0:ac:classes:password </saml:authncontextclassref> </saml:authncontext> </saml:authnstatement> <saml:attributestatement> <saml:attribute NameFormat=" Name="obligations:subject_id" xmlns:orca=" <saml:attributevalue xsi:type="orca:type"> <orca:subject_id>jbond<orca:subject_id> <saml:attributevalue> </saml:attribute> <saml:attribute NameFormat=" Name="obligations:action" xmlns:orca=" <saml:attributevalue xsi:type="orca:type"> <orca:action>authenticate<orca:action> <saml:attributevalue> </saml:attribute> <saml:attribute NameFormat=" Name="obligations:method" xmlns:orca=" <saml:attributevalue xsi:type="orca:type"> <orca:method>password<orca:method> <saml:attributevalue> </saml:attribute> </saml:attributestatement> </saml:assertion> Politechnika Poznańska /67

30 <saml:assertion xmlns:saml= urn:oasis:names:tc:saml:2.0:assertion Version="2.0" IssueInstant=" T12:00:00Z" ID="_a759we"> <saml:issuer Format=urn:oasis:names:SAML:2.0:nameid-format:entity> </saml:issuer> <ds:signature xmlns:ds=" <ds:signedinfo> <ds:canonicalizationmethod Algorithm=" <ds:signaturemethod Algorithm=" <ds:reference URI="#_a759we"> <ds:transforms> <ds:transform Algorithm=" <ds:transform Algorithm=" <InclusiveNamespaces PrefixList="#default saml ds xs xsi orca" xmlns=" </ds:transform> </ds:transforms> <ds:digestmethod Algorithm=" <ds:digestvalue> Kclet6XcaOgOWXM4gty6/UNdviI= </ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue> hq4zk+zknjggcqgzm7ea8fi7...hr7whxvccrwubfz6rqvl+wnmewi4= </ds:signaturevalue> <ds:keyinfo> <ds:x509data> <ds:x509certificate> MRIwEAYDVQQIEwlXaXNjb...6Hr7wHxvCCRwubnZAv2FU78p== </ds:x509certificate> </ds:x509data> </ds:keyinfo> </ds:signature> <saml:subject> <saml:nameid Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"> Politechnika Poznańska /67

31 </saml:nameid> </saml:subject> <saml:authnstatement AuthnInstant=" T12:00:00Z" SessionIndex=" "> <saml:authncontext> <saml:authncontextclassref> urn:orca:x.509certificate </saml:authncontextclassref> </saml:authncontext> </saml:authnstatement> <saml:attributestatement> <saml:attribute NameFormat=" Name="obligations:target_id" xmlns:orca=" <saml:attributevalue xsi:type="orca:type"> <orca:subject_id> <saml:attributevalue> </saml:attribute> <saml:attribute NameFormat=" Name="obligations:action" xmlns:orca=" <saml:attributevalue xsi:type="orca:type"> <orca:action>encrypt<orca:action> <saml:attributevalue> </saml:attribute> <saml:attribute NameFormat=" Name="obligations:method" xmlns:orca=" <saml:attributevalue xsi:type="orca:type"> <orca:method> aes128-cbc<orca:method> <saml:attributevalue> </saml:attribute> </saml:attributestatement> </saml:assertion> Politechnika Poznańska /67

32 <saml:assertion xmlns:saml= urn:oasis:names:tc:saml:2.0:assertion Version="2.0" IssueInstant=" T12:00:00Z" ID="_a75adf55"> <saml:issuer Format=urn:oasis:names:SAML:2.0:nameid-format:entity> </saml:issuer> <ds:signature xmlns:ds=" <ds:signedinfo> <ds:canonicalizationmethod Algorithm=" <ds:signaturemethod Algorithm=" <ds:reference URI="#_a75adf55"> <ds:transforms> <ds:transform Algorithm=" <ds:transform Algorithm=" <InclusiveNamespaces PrefixList="#default saml ds xs xsi orca" xmlns=" </ds:transform> </ds:transforms> <ds:digestmethod Algorithm=" <ds:digestvalue> Kclet6XcaOgOWXM4gty6/UNdviI= </ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue> hq4zk+zknjggcqgzm7ea8fi7...hr7whxvccrwubfz6rqvl+wnmewi4= </ds:signaturevalue> <ds:keyinfo> <ds:x509data> <ds:x509certificate> MRIwEAYDVQQIEwlXaXNjb...6Hr7wHxvCCRwubnZAv2FU78p== </ds:x509certificate> </ds:x509data> </ds:keyinfo> </ds:signature> <saml:subject> <saml:nameid Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"> JBond </saml:nameid> Politechnika Poznańska /67

33 </saml:subject> <saml:authnstatement AuthnInstant=" T12:00:00Z" SessionIndex=" "> <saml:authncontext> <saml:authncontextclassref> urn:oasis:names:tc:saml:2.0:ac:classes:password </saml:authncontextclassref> </saml:authncontext> </saml:authnstatement> </saml:assertion> Politechnika Poznańska /67

34 4.5 Asercje uwierzytelniania W przypadku zagnieżdżenia wywołań usług w ramach pojedynczej sesji wymagane jest propagowanie tożsamości wszystkich podmiotów, od inicjatora sesji począwszy (Originator). Potrzeba ta wynika z konieczności realizacji kontroli dostępu do usług wywoływanych w sposób zagnieżdżony, a to jak wiemy odbywa się poprzez przekazanie z modułu PEP wywoływanej usługi do PDP (podejmującego decyzje kontroli dostępu) wszystkich potencjalnie potrzebnych parametrów opisujących wywołanie. Ponieważ PEP nie może przewidzieć, jakie jest brzmienie reguł polityki, właściwych do podjęcia decyzji przez PDP (w szczególności chodzi o reguły delegacji uprawnień), zatem musi przekazać do PDP tożsamość wszystkich znanych mu podmiotów, aby umożliwić prawidłowe (kompletne) dopasowanie reguł do bieżącego wywołania. Propagację tożsamości podmiotów schematycznie przedstawia Rysunek 9. Zaprezentowana na nim przykładowa sesja rozpoczyna się w punkcie (A), w którym użytkownik U inicjator sesji (Originator), za pośrednictwem aplikacji klienckiej C (Invoker) wywołuje usługę S1. Moduł PEP S1 zgłasza zatem do PDP tożsamość i otrzymane w żądaniu dane uwierzytelniające wszystkich podmiotów, czyli tutaj U oraz C. Tożsamość wszystkich podmiotów musi być zweryfikowana przed zastosowaniem reguł polityki dotyczących tych podmiotów. Dalszy przebieg sesji jest realizowany analogicznie. PDP (A) U,C (B) U,C, S1 (C) U,C,S1, S2 (D) REQ(U,C,...) REQ(U,C,S1,...) REQ(U,C,S1,S2,...) PEP C PEP S1 PEP S2 PEP S3 C S1 S2 S3 Rysunek 9. Delegacja uprawnień w zagnieżdżeniu wywołań Można zaobserwować, iż na każdym kolejnym poziomie zagnieżdżenia pojawia się dodatkowo tylko pojedynczy podmiot (bieżący Invoker). Poprzednie podmioty były oczywiście już wcześniej uwierzytelnione (przed realizacją wywołania wcześniejszej interakcji). Zatem nieefektywne byłoby wymaganie uwierzytelnienia ich ponownie, skoro dokonano go już uprzednio w tej sesji. Wystarczy uwierzytelnić tylko nowopojawiajacy się podmiot (na rysunku wytłuszczony). Jednak, aby uniknąć podszycia się pod podmiot rzekomo wcześniej uwierzytelniony, każde pomyślne uwierzytelnienie musi być potwierdzone odpowiednią asercją przez uwierzytelniający PDP. Asercja ta jest następnie propagowane i poddawana weryfikacji na dalszych poziomach zgnieżdżenia. Politechnika Poznańska /67