Toruń 28/

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

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.

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

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

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

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.

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

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

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ą

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ą

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

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)

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

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

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

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)

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

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

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