WS-Security Framework

Podobne dokumenty
Problematyka bezpieczeństwa usług Web Services. Witold Andrzejewski

Rozproszone systemy Internetowe

Projektowanie obiektowe oprogramowania Wykład 14 Architektura systemów (1), Interoperability Wiktor Zychla 2013

INTERNET - Wrocław Usługi bezpieczeństwa w rozproszonych strukturach obliczeniowych typu grid

Spis treúci. 1. Wstęp... 11

1. Bezpieczeństwo transferu zestrukturalizowanych plików XML w sieci grid w oparciu o usługi Web Service poprzez protokół SOAP

Rozproszone systemy internetowe

Rozproszone systemy internetowe. Bezpieczeństwo usług WWW

Systemy pojedynczego logowania (Single Sign-On)

Rozproszone systemy internetowe 2. WS-Policy: specyfikacje wymagań dla usług WWW

Komunikacja i wymiana danych

Programowanie w języku Java. Wykład 13: Java Platform, Enterprise Edition (Java EE)

SIMON SAYS ARCHITECTURE! Usługi zdalne. Technologie, techniki i praktyki implementacji

Bezpieczeństwo aplikacji internetowych. Rozwój napędzany potrzebą WALLF Web Gateway. Leszek Miś, RHCA,RHCSS,Sec+ Linux Polska Sp. z o.o.

TelCOMM Wymagania. Opracował: Piotr Owsianko Zatwierdził: IMIĘ I NAZWISKO

Bezpieczne protokoły Materiały pomocnicze do wykładu

Protokół DHCP. DHCP Dynamic Host Configuration Protocol

Podpis elektroniczny dla firm jako bezpieczna usługa w chmurze. mgr inż. Artur Grygoruk

Web Services. Bartłomiej Świercz. Łódź, 2 grudnia 2005 roku. Katedra Mikroelektroniki i Technik Informatycznych. Bartłomiej Świercz Web Services

Wykorzystanie SAML 2.0 w systemie epuap

Jarosław Kuchta Administrowanie Systemami Komputerowymi. Internetowe Usługi Informacyjne

Programowanie obiektowe

Oracle COREid Federation Przegląd

Część I -ebxml. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz

Implementowanie zaawansowanej infrastruktury serwerowej Windows Server 2012 R2

Gatesms.eu Mobilne Rozwiązania dla biznesu

Specyfikacja techniczna interfejsu do obsługi Profilu Kandydata na Kierowcę.

1 Wprowadzenie do J2EE

Serwer SSH. Wprowadzenie do serwera SSH Instalacja i konfiguracja Zarządzanie kluczami

Praktyczne wykorzystanie mechanizmów zabezpieczeń w aplikacjach chmurowych na przykładzie MS Azure

Metody uwierzytelniania klientów WLAN

Simple Object Access Protocol

Jarosław Kuchta Administrowanie Systemami Komputerowymi. Dostęp zdalny

Uwierzytelnianie użytkowników sieci bezprzewodowej z wykorzystaniem serwera Radius (Windows 2008)

Problematyka bezpieczeństwa usług Web Services

Kontrola dostępu do sieci lokalnych (LAN)

Marcin Szeliga Sieć

Ministerstwo Finansów

Wykład 4. Metody uwierzytelniania - Bezpieczeństwo (3) wg The Java EE 5 Tutorial Autor: Zofia Kruczkiewicz

Protokół DHCP. DHCP Dynamic Host Configuration Protocol

PolishAPI. Rekomendacje oraz podstawowe założenia do przygotowania interfejsu awaryjnego. Dokument opracowany przez Grupę Projektową ds.

Stan zaawansowania prac dotyczących zamówienia na opracowanie i wdrożenie rdzenia systemu e Urząd.

Ochrona danych i bezpieczeństwo informacji

eidas Standardy de iure i de facto oraz rozwiązania niestandardowe

Protokół DHCP. Patryk Czarnik. Bezpieczeństwo sieci komputerowych MSUI 2010/11. Wydział Matematyki, Informatyki i Mechaniki Uniwersytet Warszawski

Architektury usług internetowych. Tomasz Boiński Mariusz Matuszek

Usługi danych przestrzennych w GEOPORTAL-u. Marek Szulc , Warszawa

System DiLO. Opis interfejsu dostępowego v. 2.0

Web Services wykład 9

Spis treści. Dzień 1. I Wprowadzenie (wersja 0906) II Dostęp do danych bieżących specyfikacja OPC Data Access (wersja 0906) Kurs OPC S7

Architektura bezpiecznych aplikacji internetowych na platformie Java Enterprise Edition. Jakub Grabowski Warszawa,

CSA STAR czy można ufać dostawcy

Kurs OPC S7. Spis treści. Dzień 1. I OPC motywacja, zakres zastosowań, podstawowe pojęcia dostępne specyfikacje (wersja 1501)

SSL (Secure Socket Layer)

PRACA INŻYNIERSKA IMPLEMENTACJA MOBILNEGO KLIENTA BANKU ZABEZPIECZONEGO TOKENEM

Zastosowania informatyki w gospodarce Wykład 7

Wybrane działy Informatyki Stosowanej

ZiMSK. Konsola, TELNET, SSH 1

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia)

Część I Dostęp do danych oraz moŝliwości programowe (silnik bazy danych)

eidas od Rozporządzenia do technicznej implementacji

5.14 JSP - Przykład z obiektami sesji Podsumowanie Słownik Zadanie... 86

Kontrola dostępu do kodu i własności intelektualnej w Zintegrowanej Architekturze. Copyright 2012 Rockwell Automation, Inc. All rights reserved.

Programowanie komponentowe. Przykład 1 Bezpieczeństwo wg The Java EE 5 Tutorial Autor: Zofia Kruczkiewicz

Dokumentacja Usług Sieciowych Uwierzytelniania i Autoryzacji. Wersja: 1.00

Zastosowania PKI dla wirtualnych sieci prywatnych

Serwery LDAP w środowisku produktów w Oracle

Ogólnopolskie Repozytorium Prac Dyplomowych

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP

Specyfikacja interfejsów usług Jednolitego Pliku Kontrolnego

Usługi sieciowe REST. Instytut Informatyki Politechnika Poznańska

EDI, XML i ochrona danych Przemysław Kazienko

Bezpieczeństwo aplikacji typu software token. Mariusz Burdach, Prevenity. Agenda

Bezpieczeństwo i szyfrowanie poczty elektronicznej z wykorzystaniem certyfikatów kwalifikowanych i niekwalifikowanych

Wprowadzenie do usług internetowych

Płatności CashBill - SOAP

Web Services. Wojciech Mazur. 17 marca Politechnika Wrocławska Wydział Informatyki i Zarządzania

Dobre praktyki w doborze technologii rozwiązań informatycznych realizujących usługi publiczne

Wypożyczalnia VIDEO. Technologie obiektowe

Wielowarstwowe aplikacje internetowe. Web Services. Autorzy wykładu: Maciej Zakrzewicz Marek Wojciechowski. Web Services

Podpis elektroniczny Teoria i praktyka. Stowarzyszeni PEMI

Identity Management w Red Hat Enterprise Portal Platform. Bolesław Dawidowicz

Zagadnienia projektowania aplikacji J2EE

Budowa wiadomości SMTP. autorzy: Aleksandra Wichert Marcin Żurowski

Regulamin Polskiej Federacji Zarządzania Tożsamością PIONIER.Id na potrzeby realizacji usługi SAML WebSSO

WSIZ Copernicus we Wrocławiu

1. Wymagania dla lokalnej szyny ESB

Usługi IMP i konferencyjne

WYMAGANIA TECHNOLOGICZNE W ODNIESIENIU DO SYSTEMÓW TELEKOMUNIKACYJNYCH I TELEINFORMATYCZNYCH W OBSZARZE SIŁ ZBROJNYCH

(Pluggable Authentication Modules). Wyjaśnienie technologii.

Bezpieczeństwo systemów komputerowych.

Programowanie współbieżne i rozproszone

Wybrane działy Informatyki Stosowanej

Wykład 3 Inżynieria oprogramowania. Przykład 1 Bezpieczeństwo(2) wg The Java EE 5 Tutorial Autor: Zofia Kruczkiewicz

Warstwa ozonowa bezpieczeństwo ponad chmurami

Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP

WSF.2. Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Innowacyjna Gospodarka

Aplikacje www laboratorium

Authenticated Encryption

Transkrypt:

Polsko-Japońska Wyższa Szkoła Technik Komputerowych WS-Security Framework Edgar Głowacki edgar@glowacki.eu 1 Współczesny szkielet (framework) warstwy pośredniej Oczekiwania względem szkieletu middleware prawdziwa a nie deklarowana interoperacyjność przejęcie odpowiedzialności za powtarzające kwestie wynikające z wymagań pozafunkcjonalnych: (1) przetwarzanie asynchroniczne, (2) bezpieczeństwo, (3) transakcyjność, OMG CORBA pierwsza próba stworzenia szkieletu middleware z prawdziwego zdarzenia właściwie dogorywająca WebServices znacznie więcej niż RPC choć wiele osób mających małą wiedzę o WS widzi w tej technologii mało udany klon RPC w rzeczywistości od roku 2001 WS były projektowane jako prawdziwy szkielet middleware 2 1

Węzły SOAP original sender intermediary ultimate receiver Model komunikacji SOAP Przetwarzanie komunikatów przez węzły bloki nagłówka dodawane, usuwane, modyfikowane przez wszystkich uczestników komunikacji ciało komunikacja między końcami Atrybuty bloku nagłówka zdefiniowane przez SOAP role (actor SOAP 1.1) mustunderstand relay 3 Global XML Web Services Architecture Specyfikacje stanowiące cegiełki (building blocks) tworzące infrastrukturę szkieletu zgodnie z paradygmatem protocol composability Specyfikacje WS-* (częściowo grupowane w szkielety) szkielet bezpieczeństwa (WS-Security, WS-Trust, WS-Federation, WS- SecureConversation, WS-SecurityPolicy) szkielet transakcyjności (WS-Coordination, WS-AtomicTransaction, WS- BusinessActivity) posiada też konkurencyjny zbiór specyfikacji szkielet niezawodnego transportu (WS-ReliableMessaging, ) łącznie ok. 70-80 różnych specyfikacji na różnym etapie rozwoju 4 2

WS-Security fundament szkieletu (1) Tunelowanie na poziomie transportu nieadekwatne dla modelu komunikacji SOAP point-to-point vs. end-to-end Zabezpieczenie na poziomie komunikatu nagłówek bezpieczeństwa <wsse: Security> zawsze co najwyżej jeden nagłówek dla danego węzła blok bez wskazanej roli może być przetwarzany przez wszystkie węzły, ale nie może być usunięty aż do osiągnięcia końca ścieżki poufność lub/i integralność XML-Encryption i XML-Signature zabezpieczanie dowolnej liczby wybranych elementów koperty SOAP 5 WS-Security fundament szkieletu (2) Żetony bezpieczeństwa jako bloki security header (określone w osobnych profilach) nazwa użytkownika/hasło, certyfikat X.509, żeton Kerberos, asercja SAML własne (proprietary) żetony bezpieczeństwa oczywiście z podaną przestrzenią nazw Znaczniki czasu mechanizm zabezpieczający przed replay attack umożliwiają przekazanie informacji o czasie utworzenia i ważności elementów chronionych przez nagłówek bezpieczeństwa nie jest to znacznik czasu w rozumieniu TSP (RFC 3161) czas nie pochodzi z autorytatywnego źródła, ale jest lokalny dla strony wstawiającej blok nagłówka 6 3

WS-Security fundament szkieletu (4) <S12:Envelope...> <S12:Header>... <wsse:security S12:mustUnderstand="false"> </wsse:security>... <wsse:security S12:role="ultimateReceiver" S12:mustUnderstand="true"> </wsse:security> </S12:Header> </S12:Envelope> źródło: [2] 7 WS-Security fundament szkieletu (5) <?xml version="1.0" encoding="utf-8"?> <S:Envelope xmlns:s="..." xmlns:wsse="..." xmlns:ds.="..." <S:Header> <wsse:security> <wsse:binarysecuritytoken ValueType="wsse:X509v3" EncodingType="wsse:Base64Binary" wsu:id="x509token"> MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i... </wsse:binarysecuritytoken> <ds:signature>... <!-- i.a. metadata: canonicalization (normalization) method, signature schema, digest algorithm --> <ds:signaturevalue>bl8jdftoeb1l/vxcmznnjpov... </ds:signaturevalue>... </ds:signature> </wsse:security> </S:Header> <S:Body wsu:id="msgbody">...</s:body> </S:Envelope> źródło: [1] 8 4

WS-Security fundament szkieletu (6) <!-- signature content compliant with XMLDSig extracted from sample security header --> <ds:signature> <ds:signedinfo> <ds:canonicalizationmethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:signaturemethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/> <ds:reference URI="#MsgBody"> <ds:digestmethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:digestvalue>lylsf0pi4wpu...</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>djbchm5gk...</ds:signaturevalue> <ds:keyinfo> <wsse:securitytokenreference> <wsse:reference URI="#MyID"/> </wsse:securitytokenreference> </ds:keyinfo> </ds:signature> źródło: [3] 9 WS-Policy WSDL to za mało (1) Autonomiczność jeden z głównych postulatów SOA konieczność przekazania informacji innych wymaganiach np. dotyczących sposobu kodowania komunikatu (np. MTOM), czy tego komu ufamy Szkielet WS-Policy kompozycja polityki asercje (atomowe warunki) i alternatywy konstruowane w oparciu o operatory: ExactlyOne, All, OneOrMore definicja polityki może być umieszczona w WSDL, bądź też WSDL może zawierać referencję do niej różne zakresy (podmioty) obowiązywania polityki (punkt końcowy, komunikat, konwersacja, ) WS-PolicyAttachment generyczny szkielet uzupełniany przez odpowiednie specyfikacje (WS-PolicyAssertions, WS-SecurityPolicy, ) 10 5

WS-Policy WSDL to za mało (2) <!-- sample policy definition compliant with WS-Policy --> <wsp:policy xmlns:sp="http://docs.oasis-open.org/ws-sx/wssecuritypolicy/200702" <!-- WS-SecurityPolicy defines security assertions --> xmlns:wsp="http://www.w3.org/ns/ws-policy"> <wsp:exactlyone> <!-- exactly one operator --> <wsp:all> <!-- first alternative --> <sp:signedparts> <sp:body/> <!-- body must be either signed --> </sp:signedparts> </wsp:all> <wsp:all> <sp:encryptedparts> <sp:body/> <!-- or encrypted --> </sp:encryptedparts> </wsp:all> <!-- second alternative --> </wsp:exactlyone> </wsp:policy> źródło: [8] 11 WS-Policy WSDL to za mało (3) <!-- associating policy with SOAP endpoint -->... <wsp:policyattachment> <wsp:appliesto> <wsp:endpointreference> <wsp:servicename Name="InventoryService"/> <wsp:porttype Name="InventoryPortType"/> <wsp:address URI="http://www.xyz.com/acct"/> </wsp:endpointreference> </wsp:appliesto> <wsp:policyreference Ref="http://www.xyz.com/acct-policy.xml"/> </wsp:policyattachment> źródło: [1] 12 6

WS-SecurityPolicy asercje bezpieczeństwa (1) Asercje określające sposób ochrony (wskazanych elementów) komunikatów integrity assertion confidentiality assertion Asercje określające wymagania względem żetonów token inclusion dołączenie żetonu do komunikatu token issuer zaufana trzecia strona wymaganie dotyczące rodzajów żetonów i sposobu ich uzyskania: UsernameToken, X509Token, SecurityConversationToken 13 WS-SecurityPolicy asercje bezpieczeństwa (2) <wsp:policy...> <wsp:exactlyone> <!-- X.509 certificate is preferred over Kerberos token --> <wsse:securitytoken TokenType="wsse:X509v3" wsp:usage="wsp:required" wsp:preference="50"/> <wsse:securitytoken TokenType="wsse:Kerberosv5TGT" wsp:usage="wsp:required" wsp:preference="10"/> </wsp:exactlyone> </wsp:policy> źródło: [1]... <wsp:policy...> <sp:secureconversationtoken> <sp:issuer> <wsa:address>http://example.org/sts</wsa:address> </sp:issuer>... </sp:secureconversationtoken> </wsp:policy>... źródło: [3] 14 7

WS-Trust budowa relacji zaufania (1) Model zaufania WS wzorowany na Kerberos w polityce usługa może zażądać by żądający (requestor) przedstawił w komunikacie dowody swoich uprawnień (roszczeń) (proof of claims), które powinny być zawarte w żetonie bezpieczeństwa jeśli klient (requestor) takowych nie posiada może uzyskać je od STS STS może przeprowadzić uwierzytelnienie i autoryzację również usługa może zwrócić się do STS o weryfikację żetonu otrzymanego od klienta źródło: [4] 15 WS-Trust budowa relacji zaufania (2) Przykłady wariantów architektury zaufania zgodne z WS-Trust STS sam może być był usługą z określoną polityką wymagającą przedstawienia żetonów bezpieczeństwa w architekturze zaufania wykorzystującej pośrednika (brokered trust) żeton może być uzyskany od STS a następnie dołączony do nagłówka przez węzeł pośredniczący Funkcjonalność STS (przykładowy WSDL [5]) wystawienie żetonu lub kolekcji żetonów walidacja anulowanie odnowienie 16 8

WS-Trust budowa relacji zaufania (3) Możliwa wymiana challenge/response z usługą STS poprzedzająca wystawienie żetonu signature challenge user interaction challenge źródło: [4] 17 WS-Trust sample signature challenge (1) <!-- initial request signed with private key corresponding to attached certificate --> <S11:Envelope...> <S11:Header>... <wsse:security> <wsse:binarysecuritytoken wsu:id="reqtoken" ValueType="...X509v3">MIIEZzCCA9C... </wsse:binarysecuritytoken> <!-- X.509 token --> <ds:signature...>... <!-- signature issued with --> <ds:keyinfo> <!-- corresponding private key --> <wsse:securitytokenreference> <wsse:reference URI="#reqToken"/> </wsse:securitytokenreference> </ds:keyinfo> </ds:signature> </wsse:security>... </S11:Header> <S11:Body> <wst:requestsecuritytoken> <wst:tokentype>http://example.org/token</wst:tokentype> <wst:requesttype>http://docs.oasis-open.org/ws-sx/wstrust/200512/issue</wst:requesttype> </wst:requestsecuritytoken> </S11:Body> </S11:Envelope> źródło: [4] 18 9

WS-Trust sample signature challenge (2) <!-- to prevent replay attack (e.g. timestamp has not been included in the request) STS issues a challenge to be signed by requestor --> <S11:Envelope...> <S11:Header>... <wsse:security> <wsse:binarysecuritytoken wsu:id="issuertoken" ValueType="...X509v3 >DFJHue... </wsse:binarysecuritytoken> <ds:signature...>... </ds:signature> </wsse:security>... </S11:Header> <S11:Body> <wst:requestsecuritytokenresponse> <wst:signchallenge> <!-- sign the below challenge with the key endorsed by the trusted third party --> <wst:challenge>huehf...</wst:challenge> </wst:signchallenge> </wst:requestsecuritytokenresponse> </S11:Body>... </S11:Envelope> źródło: [4] 19 WS-Trust sample signature challenge (3) <!-- in reply the requestor signs the message as specified in WS-Security --> <S11:Envelope...> <S11:Header>... <wsse:security> <wsse:binarysecuritytoken wsu:id="reqtoken" ValueType="...X509v3">MIIEZ... </wsse:binarysecuritytoken> <ds:signature xmlns:ds="...">... </ds:signature> </wsse:security>... </S11:Header> <S11:Body> <wst:requestsecuritytokenresponse> <wst:signchallengeresponse> <wst:challenge>huehf...</wst:challenge> </wst:signchallengeresponse> </wst:requestsecuritytokenresponse> </S11:Body> </S11:Envelope> źródło: [4] 20 10

WS-Trust sample signature challenge (4) <!-- STS returns a collection of requested tokens: (1) a custom token and (2) a shared key --> <S11:Envelope...> <S11:Header>... <wsse:security>... </wsse:security>... </S11:Header> <S11:Body> <wst:requestsecuritytokenresponsecollection> <wst:requestsecuritytokenresponse> <wst:requestedsecuritytoken> <xyz:customtoken...>... </xyz:customtoken> </wst:requestedsecuritytoken> <wst:requestedprooftoken> <xenc:encryptedkey Id="newProof >... </xenc:encryptedkey> </wst:requestedprooftoken> </wst:requestsecuritytokenresponse> </wst:requestsecuritytokenresponsecollection> </S11:Body> </S11:Envelope> źródło: [4] 21 WS-Trust user interaction challenge (1) <!-- initial request containing username and password in plaintext --> <S11:Envelope...> <S11:Header>... <wsse:security> <wsse:usernametoken> <wsse:username>zoe</wsse:username> <wsse:password Type="http://...#PasswordText"> ILoveDogs </wsse:password> </wsse:usernametoken> </wsse:security>... </S11:Header> <S11:Body> <wst:requestsecuritytoken> <wst:tokentype> http://example.org/customtoken </wst:tokentype> <wst:requesttype>...</wst:requesttype> </wst:requestsecuritytoken> </S11:Body> </S11:Envelope> źródło: [4] 22 11

WS-Trust user interaction challenge (2) <!-- STS sends a challenge for a PIN --> <S11:Envelope...> <S11:Header>... </S11:Header> <S11:Body> <wst:requestsecuritytokenresponse> <wst14:interactivechallenge xmlns:wst14="..." > <wst14:textchallenge RefId=http://docs.oasis-open.org/ws-sx/wstrust/200802/challenge/PIN Label="Please enter your PIN"/> </wst14:textchallenge> </wst14:interactivechallenge> </wst:requestsecuritytokenresponse> </S11:Body> </S11:Envelope> źródło: [4] 23 WS-Trust user interaction challenge (3) <!-- requestor application displays dialog soliciting PIN and sends it back to the STS afterward --> <S11:Envelope...> <S11:Header>... </S11:Header> <S11:Body> <wst:requestsecuritytokenresponse> <wst14:interactivechallengeresponse xmlns:wst14="..." > <wst14:textchallengeresponse RefId="http://docs.oasis-open.org/ws-sx/wstrust/200802/challenge/PIN"> 9988 </wst14:textchallengeresponse> </wst14:interactivechallengeresponse> </wst:requestsecuritytokenresponse> </S11:Body> </S11:Envelope> źródło: [4] 24 12

WS-Trust zastosowanie żetonu określa polityka Schemat uwierzytelnienia dostarczy nam żeton wymagany przez politykę usługi Żeton jest następnie dołączony do nagłówka bezpieczeństwa komunikatu przekazanego odbiorcy, którym może być: ultimate receiver intermediary 25 WS-Federation federacja domen zaufania WS Integracja przekraczająca granice domen zaufania (trust realms) oparta o współdzielenie dowodów tożsamości (identities) dodatkowej informacji o żądającym (np. imię i nazwisko) na zasadach regulujących federację i z uwzględnieniem zasad prywatności. (Przykładowo podczas korzystania ze sfederowanej usługi ujawniana jest jedynie informacja, że żądającym jest pracownik instytucji partnerskiej bez podawania danych osobistych) tzw. meta-danych federacji 26 13

WS-Federation meta-dane federacyjne usługi Meta-dane federacyjne usługi opis sposobu wykorzystania usługi w ramach federacji w tym przede wszystkim określenie roli: (1) usługa docelowa zasób (resource), (2) STS, (3) identity provider, (4) attribute service, (5) pseudonym service uzupełnienie WSDL i polityki podobnie jak polityka mogą być dołączane do usługi na zasadach określonych WS-PolicyAttachment podobnie jak polityka mogą mieć różny zasięg (scope) określany przez WS-PolicyAttachment: usługę, punkt końcowy, czy komunikat podobnie jak polityka meta-dane federacji mogą być dostępne za pomocą WS-MetadataExchange (WS-MEX) rekurencyjny dostęp do meta-danych usług powiązanych poprzez referencje konieczne do określenia pełnych wymagań usługi 27 WS-Federation Identity Provider (IP) Identity Provider usługa dostarczająca żetony bezpieczeństwa potwierdzające tożsamość klienta względem usługi odpowiednik Key Distribution Center (Authentication Server + Ticket Granting Service) znanego z protokołu Kerberos usługa IP może być łączona z lokalnym STS (na diagramie przedstawiono zdalny STS) źródło: [6] 28 14

WS-Federation model bezpieczeństwa Model bezpieczeństwa meta-dane federacyjne umożliwiają klientowi (requestor) uzyskanie informacji o rodzajach żetonów wymaganych przez usługę docelową zgodnie z WS-Trust klient ubiega się o tzw. początkowy żeton identyfikujący (initial security token) u lokalnego IP/STS żeton identyfikujący pozwala na uzyskanie żetonów u IP/STS obcych domen żeton identyfikujący może również bezpośrednio umożliwić korzystanie z usług w innych domenach zaufania 29 WS-Federation kontrola prywatności Zapewnienie prywatności w ramach federacji kontrola dostępu do danych osobowych przez klienta używanie względnie losowych identyfikatorów (pseudonimów patrz. dalej) w celu utrudnienia niepożądanej korelacji tożsamości używanych w ramach różnych domen zaufania 30 15

WS-Federation Attribute Service (AS) Attribute Service dodatkowa informacja o kliencie (requestor) może być potrzebna w celu realizacji żądania, bądź personalizacji możliwość dostępu do danych wrażliwych o kliencie tylko po odpowiedniej autoryzacji z jego strony 31 WS-Federation Pseudonym Service (PS) Pseudonym Service konieczność automatycznego mapowania tożsamości używanych w różnych domenach usługa PS umożliwia danemu podmiotowi (principal) używanie różnych aliasów w czasie dostępu do poszczególnych domen, bądź zasobów czas istnienia pseudonimów może być dowolny: (1) na stałe, (2) na czas interakcji (sesji) użytkownika, lub (3) pojedynczego dostępu do usługi mapowanie identyfikatorów może być przeprowadzone przez (1) IP/STS w trakcie tworzenia żetonu na potrzeby dostępu do usługi, (2) przez samą usługę, bądź też (3) klienta po otrzymaniu żetonu dla usługi 32 16

WS-Federation federacja domen zaufania WS (7) źródło: [6] 33 WS-Federation federacja domen zaufania WS (8) 1a) Żądający uwierzytelnia się względem IP/STS własnej domeny 2) Żądający komunikuje się z IP/STS zasobu w celu uzyskania żetonu umożliwiającego dostęp do zasobu 3) IP/STS zasobu zarejestrował pseudonim żądającego (np. na czas dostępu do zasobów danej domeny). Pseudonim może być uzupełniony o odpowiednie atrybuty dostarczone przez żądającego z odpowiednimi obostrzeniami związanymi z autoryzacją dostępu. 4) Żądający korzysta z usługi 5) Usługa korzysta z atrybutów żądającego po wcześniejszej autoryzacji u swojego IP/STS (1c) 1b) IP/STS żądającego rejestruje atrybuty klienta lub też IP/STS żądającego pobiera wcześniej zarejestrowany pseudonim żądającego wówczas może nie być potrzeby wykonania kroku (2) i (3) 34 17

WS-Federation topologie zaufania (1) Scenariusz najprostszy źródło: [6] W kroku 2. obcy STS może wydać nowy żeton, bądź też odpowiednio certyfikować żeton uzyskany w kroku 1. 35 WS-Federation topologie zaufania (2) Usługa docelowa przedstawia obcy żeton własnemu STS w celu walidacji i autoryzacji. źródło: [6] 36 18

WS-Federation topologie zaufania (3) Relacja zaufania może być przechodnia źródło: [6] 37 WS-Federation rzeczywiste scenariusze (1) Zasób wywołuje usługę spoza własnej domeny w imieniu żądającego. Zasób może ale nie musi pełnić w tym przypadku rolę węzła pośredniczącego. źródło: [6] 38 19

WS-Federation rzeczywiste scenariusze (1) Wariant poprzedniego scenariusza klient delegował swoje uprawnienia na usługę pośredniczącą. Zasób bezpośrednio wywoływany może pełnić rolę intermediary. źródło: [6] 39 WS-SecureConversation zabezpieczanie sesji (1) Problem wydajności WS-Security zabezpieczanie każdego komunikatu z osobna potrzeba wprowadzenia sprawdzonego mechanizmu jakim jest kontekst bezpieczeństwa (znanego z SSL/TLS, IPSec, czy SSH) zawierający m.in. współdzielony klucz sesyjny WS-SecureConversation rozszerzenie WS-Security wykorzystujące mechanizmy WS-Trust SecurityContextToken nowy rodzaj żetonu umieszczanego w nagłówku bezpieczeństwa zawierający unikalny identyfikator kontekstu wykorzystywanego przez strony konwersacji 40 20

WS-SecureConversation zabezpieczanie sesji (2) Ustalanie i dystrybucja kontekstu bezpieczeństwa wymaga interakcji przy użyciu odpowiedniego protokołu challenge/response przed rozpoczęciem sesji API zbliżone do STS opisane w WS-Trust komunikacja związana z wystawieniem i odnowieniem kontekstu oparta o schemat WS-Trust [7] dystrybuowany tajny klucz sesyjny jest zawsze opakowywany przez element wst:requestedprooftoken Sposoby ustalania kontekstu bezpieczeństwa STS w oparciu o API WS-Trust [5] jedna ze stron ustala i rozpowszechnia żeton pozostali mogą go odrzucić negocjacja zależna od konkretnego rozwiązania (zaleca się schemat WS- Trust) 41 Podsumowanie (1) WS względnie udana próba zapewnienia interoperacyjności WS są powszechnie stosowane niestety wykorzystanie WS jest najczęściej ograniczone do specyfikacji objętych przez profil interoperacyjności WS-I Basic Profile (WS-I BP) i to też nie w ostatniej wersji (1.2) obejmującej WS-Addressing WS-I BP znakomicie obrazuje stopień adopcji WS przez rynek najnowsza wersja 1.2 poza SOAP, WSDL i UDDI zawiera też MTOM i WS- Addressing 42 21

Podsumowanie (2) WS-* powoli zyskują na popularności specyfikacje dojrzewają proces powstawania WS-* jest równie chaotyczny i burzliwy jak niegdyś prace nad OMG CORBA użycie WS-* staje się coraz powszechniejsze ze względu na wsparcie ze strony implementacji: Microsoft WCF (wcześniej eksperyment WSE), rozszerzenia Axis2,... WS-* coraz częściej wykorzystywane jest również w produktach (np. w realizacji SSO przez Novell AC 3.1 w dostępie użytkowników niekorzystających z produktów Microsoft do witryn wykorzystujących Windows Authentication Provider) 43 Źródła informacji [1] http://www.developer.com/services/article.php/2171031 [2] http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy- 1.2-spec-os.pdf [3] http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os- SOAPMessageSecurity.pdf [4] http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.pdf [5] http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/cd/ws-trust-1.4.wsdl [6] http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-specos.pdf [7] http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.xsd [8] WS-Policy Framework 1.5 44 22

Dziękuję za uwagę 45 23