Toruń 28/29.10.2014. REFEDS Konfederacje eduGAIN – eduGAIN w działaniu – Skutki obecności w eduGAIN – Jakie usługi powinny być w eduGAIN.

Prezentacja na temat: "Toruń 28/29.10.2014. REFEDS Konfederacje eduGAIN – eduGAIN w działaniu – Skutki obecności w eduGAIN – Jakie usługi powinny być w eduGAIN."— Zapis prezentacji:

1 Toruń 28/29.10.2014

2 REFEDS Konfederacje eduGAIN – eduGAIN w działaniu – Skutki obecności w eduGAIN – Jakie usługi powinny być w eduGAIN

3 https://refeds.org Międzynarodowa grupa robocza pracująca nad najistotniejszymi tematami w zakresie zarządzania tożsamością w kontekście akademickich i naukowych federacji Platforma wymiany informacji między federacjami Koordynacja regulaminów Federacji Prace nad podwyższeniem poziomu zaufania do procesu uwierzytelnienia i autoryzacji (LOA) Prace nad specyfikacjami kategorii obiektów

4 Konfederacja to federacja federacji Członkowie konfederacji przyjmują pewne ustalenia bazowe i ogólny regulamin Federacje członkowskie muszą działać w oparciu o założenie, że procedury i zasady działania innych federacji mogą odbiegać od przyjętych w obrębie danej federacji Federacje skupione w konfederacji powinny dążyć do maksymalnego uspójnienia zasad i stosowanego nazewnictwa Przykładami konfederacji są eduroam i eduGAIN

5 http://www.edugain.org/technical/status.php eduGAIN jest konfederacją o ogólnoświatowym zasięgu, skupiającą akademickie i naukowe federacje zarządzania tożsamością (koniec października 2014 – 27 federacji krajowych) rozwój i utrzymanie eduGAIN jest jednym z zadań projektu GEANT Główny cel eduGAIN – ograniczenie sytuacji, w których jeden Dostawca Usługi musi się rejestrować we wszystkich federacjach na świecie Techniczne działanie eduGAIN polega na utrzymywaniu zaufanego źródła metadanych powstającego jako agregat metadanych przekazywanych przez federacje członkowskie Utrzymanie infrastruktury eduGAIN – M.Górecka-Wolniewicz, T. Wolniewicz w imieniu PCSS

6 Federacje członkowskie przygotowują zbiory metadanych i podpisują je cyfrowo kluczem wcześniej uzgodnionym z operatorami eduGAIN eduGAIN scala metadane, kontrolując ich poprawność i fakt, że wszystkie obiekty mają prawidłowe wskazanie federacji macierzystej, a następnie podpisuje metadane własnym kluczem Dane dostępne są publicznie, pod adresem http://mds.edugain.org/, ale nie są przeznaczone pobierania bezpośrednio przez SP i IdP.http://mds.edugain.org/ Federacje członkowskie pobierają metadane z eduGAIN, mogą je poddać lokalnej obróbce, podpisują własnym kluczem i udostępniają własnym członkom/partnerom SP i IdP należące do federacji pobierają metadane eduGAIN z repozytorium swojej federacji i instalują je w swoich systemach PIONIER.Id udostępnia trzy zbiory: – metadane PIONIER.Id – zagregowane metadane PIONIER.Id i eduGAIN – tylko SP – zagregowane metadane PIONIER.Id i eduGAIN – tylko IdP

7 IdP SP

8 Wszystkie IdP i wszystkie usługi, których metadane zostały przekazane do eduGAIN powinny pobierać metadane wszystkich potencjalnych partnerów, tak by nie były generowane błędy wynikające z braku metadanych Wskazane jest, aby SP utrzymujące własną usługę WAYF ograniczały listę IdP do tych, z którymi są skłonne współpracować Wskazane jest, by SP miały przejrzysty system raportowania błędów wynikających z braku wymaganych atrybutów

9 Największe szanse na zdobycie szerokiej gamy użytkowników mają usługi o bardzo wąskim zbiorze wymaganych atrybutów Bardzo korzystne jest zakwalifikowanie usługi do jednej z kategorii obiektów wspieranych przez eduGAIN, bo IdP mogą globalnie ustawiać politykę akceptowania SP z danej kategorii Czy ma sens eksportowanie do eduGAIN zasobów lokalnych – tak, bo jest to metoda na dopuszczenie do nich wybranych użytkowników z całego świata – nie, bo większość użytkowników, którzy będą chcieli się zalogować zostanie odrzuconych z powodu braku autoryzacji

10 Podstawowy obowiązek IdP – importowanie metadanych wszystkich SP z eduGAIN, nawet takich Obowiązek SP – importowanie metadanych IdP, które mogą się pojawiać w usłudze WAYF

11 Wymiana metadanych własnej federacji jest oparta o regulamin tej federacji Wymiana metadanych między różnymi federacjami oznacza, że podmioty mogą działać na nieco innych zasadach formalnych eduGAIN wymaga, by federacje członkowskie przedstawiły do akceptacji regulaminy i procedury rejestracji, co zapewnia znaczne podobieństwo, ale niekoniecznie identyczność procedur. Metadane dostawców usług konkretnej federacji są badane pod kątem np. zasadności pozyskiwania atrybutów, w przypadku eduGAIN, takie sprawdzenie robi inna federacja, a zatem standardy mogą się różnić

12 Obecnie w eduGAIN pojawia się sporo IdP i SP, które nie są jeszcze gotowe do współpracy Typowe problemy – na liście WAYF brakuje wielu IdP – być może SP w ogóle nie importuje metadanych eduGAIN, być może jest otwarte na współpracę z jedynie wąską grupą IdP, które konfiguruje ręcznie – IdP znajduje się na liście, ale uwierzytelnienie nie dochodzi do skutku bo: IdP nie posiada danych SP IdP nie udostępnia atrybutów wymaganych przez SP – IdP jest na liście, uwierzytelnienie działa, ale usługi nie można używać z powodu braku autoryzacji takiej sytuacji nie można uważać za błąd, jest ona naturalna dla usług, które nie mają charakteru powszechnego, uprawnienia mogą być ustawiane nawet per indywidualny użytkownik

13 Udostępnianie danych zawsze jest obarczone pewnym ryzykiem W świetle opinii GIODO na temat danych IP uprawniony jest wniosek, że udostępnienie identyfikatora pseudoanonimowego jest bezpieczne, a zatem usługodawcy, którzy oczekują wyłącznie tej informacji mogą być automatycznie akceptowani

14 Pojęcie kategorii obiektów (entity cathegory) wprowadzono w celu klasyfikacji obiektów do grup określających zastosowanie usług W przypadku usług, zadeklarowanie wsparcia dla danej kategorii może oznaczać np. stosowanie dodatkowych procesów dotyczących przetrwania danych osobowych, ograniczenie celów, jakim służy dana usługa itp. W przypadku IdP zadeklarowanie wsparcia jest informacją, ze IdP będzie wysyłało minimalny zestaw atrybutów określony w rakach danej kategorii do wszystkich SP, które taką kategorię deklarują Nadania kategorii dokonuje Federacja na wniosek partnera lub członka Federacji

15 <saml:Attribute Name="http://macedir.org/entity-category" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> http://refeds.org/category/research-and- scholarship

16 Research and Scholarship Kategoria zdefiniowana przez REFEDS – przewidziana głównie dla narzędzi współpracy akademickiej, jakich jak wiki, blogi, portale zarządzania projektami – dostawcy treści objętych licencją, np. czasopisma elektroniczne, nie kwalifikują się do tej kategorii – usługodawca deklaruje, że nie będzie udostępniał, ani wykorzystywał pozyskanych danych w celach wykraczających poza definicję usługi ka kategorii R&S Minimalny zestaw udostępnianych atrybutów, to: eduPersonPrincipalName; mail; displayName lub (givenName i sn)

17 Kategoria porządkująca kwestie przetwarzania danych osobowych w celu ułatwienia IdP podjęcia decyzji o udostępnianiu atrybutów W przypadku usługodawców z EU i krajów, których ustawodawstwo w dziedzinie ochrony danych osobowych jest uważanie za zgodne z europejskim, CoC nie wnosi w zasadzie żadnych nowych treści. CoC proponuje szablon Polityki Prywatności, który powinien ułatwić interoperacyjność. Sugerujemy, aby polscy usługodawcy korzystali z szablonu CoC

18 Wzrost liczebności federacji krajowych powinien ulec zahamowaniu – nie ma potrzeby przyłączać wszystkich usług do federacji lokalnych, skoro mogą one zostać pobrane z eduGAIN Federacje krajowe będą uzyskiwały szerszy łatwiejszy dostęp do usług, zwłaszcza niszowych, niekomercyjnych Rola federacji krajowych zostanie rozszerzona o weryfikację prawidłowego deklarowania kategorii obiektów

19