Toruń 28/29.10.2014. Zadania Federacji – Źródło informacji o IdP i SP – Podstawa zaufania – Tworzenie wspólnego języka – Dbanie o formalności – Przygotowanie.

Prezentacja na temat: "Toruń 28/29.10.2014. Zadania Federacji – Źródło informacji o IdP i SP – Podstawa zaufania – Tworzenie wspólnego języka – Dbanie o formalności – Przygotowanie."— Zapis prezentacji:

1 Toruń 28/29.10.2014

2 Zadania Federacji – Źródło informacji o IdP i SP – Podstawa zaufania – Tworzenie wspólnego języka – Dbanie o formalności – Przygotowanie filtrów udostępniania atrybutów – Doradztwo – Pozyskiwanie partnerów Modele Federacji – Mesh – Hub & Spoke Współpraca między federacjami Federacja a technologia

3 Usługodawcy – usługa otwarta na wszystkich członków federacji musi mieć źródło danych, aby wiedzieć z kim (tzn. z jakimi IdP) może rozmawiać – usługi o zamkniętym zbiorze odbiorców mogą korzystać z informacji o wszystkich IdP w celu odnajdowania potencjalnych klientów Instytucje uwierzytelniające – IdP muszą mieć informację z jakich usług mogą potencjalnie korzystać Federacja może prowadzić centralną listę IdP (tzw. WAYF – Where Are You From) podłączaną do SP jako usługa zdalna.

4 Pomiędzy stronami komunikacji następuje wymiana danych – SP musi ufać, że rozmawia z właściwym IdP informacja od IdP jest wiarygodna – IdP musi ufać, że rozmawia z właściwym SP wysyłane dane są odpowiednio zabezpieczone Federacja dystrybuuje wiarygodny zestaw metadanych – metadane zawierają powiązanie między identyfikatorami stron i certyfikatami zabezpieczającymi dane – Federacja gwarantuje, że wszystkie strony stosują odpowiednie klucze zabezpieczające

5 Słownik atrybutów – autoryzacja (nadawanie uprawnień do zasobu) często jest realizowana w oparciu o konkretne atrybuty, np.: dostęp do bazy danych mają pracownicy, ale studenci nie dostęp do zasobu mają tylko osoby z danego wydziału – Federacja ustala wspólny słownik terminów Dokumenty i regulaminy – jednorodność nazewnictwa – jednorodność zasad – wspólne szablony dokumentów

6 Partnerzy i członkowie PIONIER.Id muszą spełniać pewne wymogi formalne, np.: – Partnerzy muszą publikować Politykę Prywatności dla każdej ze swoich usług – Członkowie muszą wdrożyć zasady zarządzania kontami użytkowników, tak by dawać gwarancje, że konta są osobiste oraz informacja o udostępnianych atrybutach jest wiarygodna – Instytucja Partnera musi być wiarygodna, np. być ulokowana w kraju mającym odpowiednie prawo ochrony danych osobowych Jednymi z zadań Operatora Federacji jest: – sprawdzenie spełniania wymagań formalnych – sprawdzenie, że wymagania SP dotyczące atrybutów są zgodne z faktycznymi potrzebami konkretnych usług

7 Odpowiedzialność za prawidłowe udostępnianie danych użytkowników należy do IdP, ale – operator federacji może przygotować zestaw zaleceń zgodnych z wynikami analizy potrzeb usługodawcy, tzw. filtrów atrybutów Operatorzy IdP powinni przeglądać przygotowane filtry, ale praktyka innych federacji pokazuje, ze zazwyczaj filtry mogą być zastosowane bez modyfikacji.

8 Tematyka zarządzania tożsamością jest stosunkowo złożona zarówno technicznie jak i formalnie, dlatego osoby odpowiedzialne za prowadzenie federacji muszą prowadzić rozbudowane wsparcie w zakresie: – technicznym instalacji i konfiguracji oprogramowania rozwiązywania problemów wdrażania nowych rozwiązań – formalnym interpretacji zapisów regulaminu przygotowywania regulaminów wewnętrznych przygotowywania dokumentów opisowych wspomagających podejmowanie decyzji

9 Federacja ma wartość tylko, jeżeli daje dostęp do ważnych usług, dlatego ważną rolą operatora federacji jest pozyskiwanie partnerów, a więc: – zainteresowanie potencjalnych partnerów udziałem w federacji – prowadzenie uzgodnień technicznych – uzgadnianie minimalnego, niezbędnego zestawu atrybutów – doprowadzenie do podpisania formalnego zgłoszenia Problem jajka i kury – SP czekają na większą grupę IdP i odwrotnie

10 W tym modelu rola Federacji ogranicza się do opisanych wcześniej zadań Cała komunikacja pomiędzy stronami odbywa się bezpośrednio Federacja nie bierze żadnej odpowiedzialności za decyzje IdP w sprawie udostępniania atrybutów, ochrony danych osobowych W ramach infrastruktury technicznej Federacji nie następuje żadne przetwarzanie danych osobowych Model przyjęty przez m.in. federacje: amerykańską, brytyjską, szwajcarską, niemiecką, francuską, czeską, fińską, szwedzką, polską

11 Federacja jest punktem centralnym całego ruchu uwierzytelniania każde SP i każde IdP konfiguruje tylko jeden punkt uwierzytelniania Federacja udostępnia mechanizmy filtrowania atrybutów i filtruje atrybuty zgodne z ustawieniami ustalanymi przez administratorów IdP Federacja uczestniczy w przetwarzaniu danych osobowych, chociaż nie utrzymuje żadnych baz Federacja posiada pełną informację o wykonywanych uwierzytelnieniach Federacja często negocjuje kontrakty na globalny dostęp do usług Model przyjęty przez m.in. federacje: holenderską, duńską, norweską, hiszpańską, chorwacką

12 Krajowe federacje zarządzania tożsamością coraz silniej współpracują m in. w obszarach – rozwoju standardów zarządzania tożsamością – użytkowania i rozwijania oprogramowania – ustalania wspólnych, przejrzystych zasad, m.in. w celu lepszego rozumienia swoich regulaminów – tworzenia konfederacji, tj. systemu, w którym można korzystać z usług udostępnianych przez inne federacje bez potrzeby włączania ich do własnej

13 Federacja krajowa – reprezentuje swoich członków w pracach konfederacji – odpowiada za właściwe przygotowanie metadanych do eksportu do konfederacji – przygotowuje metadane pobrane z konfederacji na potrzeby swoich odbiorców – zapewnia właściwą klasyfikację obiektów metadanych (poprzez tzw. kategorie obiektów)

14 Oprogramowanie – Shibboleth, simpleSAMLphp, OpenSAML - wady i zalety – Instalacja Identity Providera Shibboleth simpleSAMLphp simpleSAMLphp - własna baza dla IdP w 15 minut atrybuty, tworzenie, mapowanie itd. zgoda użytkownika (Consent) generowanie i rejestracja metadanych – Instalacja SP simpleSAMLphp Shibboleth proste API z użyciem SSP Discovery Service i korzystanie z zewnętrznej usługi WAYF generowanie i rejestracja metadanych Czego oczekujemy od partnerów MAN-HA

15 SAML – standard OASIS stworzony na potrzeby rozproszonego zarządzania tożsamościąOASIS – SAML powstał przy silnym współudziale Intrenet2 pracującego nad implementacją oprogramowanie ShibbolethIntrenet2 Shibboleth OpenID – technologia uwierzytelniania tworzona przez OpenID Foundation obecnie w odwrocie, np. Google zapowiedział wyłączenie wsparcia dla tego protokołuOpenID Foundation OAuth – otwarta technologia autoryzacji rozwijana w ramach IETF OpenId Connect – technologia uwierzytelniania zbudowana na bazie protokołu OAuth 2.0 RADIUS – protokół uwierzytelniania stworzony w ramach IETF nie dostosowany do potrzeb federacyjnego zarządzania tożsamością w usługach WWW

16 Użycie w Federacjach naukowych – SAML 2.0 jest podstawą działania obecnych federacji – OpenID pojawia się coraz częściej, w celu współpracy z usługami, które zostały zbudowane w oparciu o ten standard – OAuth jest postrzegane jako ważne narządzie, które może wspomagać bardziej rozbudowane modele autoryzacji, tzw. wirtualne organizacje, zewnętrzni dostawcy atrybutów, agregowane tożsamości itp. – RADIUS – powszechnie używany w eduroam, ale nie w federacyjnym zarządzaniu tożsamością w usługach WWW

17 Polecany dokument – SAML V2.0 Technical OverviewSAML V2.0 Technical Overview Asercja (SALM assertion) – Komunikat przekazywany przez IdP (lub Attribute Authority) do SP będący potwierdzeniem statusu użytkownika. Asercje SAML mogą zawierać trzy rodzaje stwierdzeń: potwierdzenia uwierzytelnienia (authentication statements) informacje o atrybutach (attribute statements) potwierdzenia uprawnień (authorization decission statements)

18 SAML protocol – protokół dedykowany konkretnej funkcji np.: Authentication Request Protocol Assertion Query and Request Protocol: Single Logout Protocol SAML binding – definicja realizacji protokołów SAML w proptokołach niższego poziomu np.: HTTP Redirect Binding HTTP POST Binding SAML SOAP Binding

19 SAML profile – definicja dodająca definicje (ograniczenia) na stosowanie SAML w celu osiągnięcia konkretnego celu i zmaksymalizowanie interoperacyjności – Web Browser SSO Profile Web Browser SSO Profile – saml2int saml2int Interoperable SAML 2.0 Profile - profil SAML stworzony na bazie Web Browser SSO Profile przez akademickie federacje zarządzania tożsamością mający na celu znaczące doprecyzowanie formatu i znaczenia informacji zawartej zarówno w metadanych, jak i asercjach SAML, uwzględniający typowe potrzeby Web SSO. saml2int jest wspierany przez większość federacji akademickich i jest podstawą interoperacyjności w ramach eduGAIN. saml2int jest profilem wymaganym przez eduGAIN

20 Konstrukcja eduroam ma wiele cech federacji typu hub & spoke Niektóre federacje (np. szwedzka SWAMID) taktują eduroam i federacje oparte o SAML jako realizacje techniczne tego samego procesu – mają jeden regulamin ramowy – mają regulaminy techniczne dotyczące każdej realizacji Wdrożenie w eduroam uwierzytelniania opartego o DNS oraz protokół RADIUS-over-TLS zbliży eduroam do modelu mesh Z powodu zasadniczych różnych między protokołami oraz znacznie większej gamy zagadnień dotyczących ochrony danych osobowych, eduroam i federacje są jednak zazwyczaj realizowane odrębnie Naturalne jest, aby IdP korzystały z tej samej bazy użytkowników na potrzeby obu usług Federacje SAML rozważają wdrożenie mechanizmów wspierających zbieranie statystyk, podobnych jak wdrożone w eduroam F-Ticks

21