Zarządzanie tożsamością Promotor: Prof. dr hab. Zbigniew Kotulski 17 kwietnia 2007 Dominik Zasiewski.

Prezentacja na temat: "Zarządzanie tożsamością Promotor: Prof. dr hab. Zbigniew Kotulski 17 kwietnia 2007 Dominik Zasiewski."— Zapis prezentacji:

1 Zarządzanie tożsamością Promotor: Prof. dr hab. Zbigniew Kotulski 17 kwietnia 2007 Dominik Zasiewski

2 Zarządzanie tożsamością Konspekt prezentacji I.Cele systemów zarządzania tożsamością II.Podział systemów zarządzania tożsamością III.Systemy oparte o federacje tożsamości IV.Systemy scentralizowane wokół użytkowników

3 Zarządzanie tożsamością I. Cele systemów zarządzania tożsamością Nowa funkcjonalność  SSO (Single Sign On), współdzielenie informacji Bezpieczeństwo Współpraca z różnymi standardami Skalowalność i elastyczność Ochrona prywatności

4 Zarządzanie tożsamością I. Wytyczne do oceny systemów zarządzania tożsamością

5 Zarządzanie tożsamością II. Podział systemów zarządzania tożsamością Single - domain  Np.. systemy działające w obrębie jednej korporacji Cross - domain  Np.. systemy (platformy) działające w Internecie, lub pomiędzy różnymi korporacjami

6 Zarządzanie tożsamością II. Podział systemów zarządzania tożsamością – Single domain Systemy: Kerberos, Active Directory (protokół LDAP) Funkcjonalność: SSO Wady:  brak skalowalności,  brak zgodności pomiędzy różnymi systemami  brak prywatności (chociaż to nie jest w zasadzie wymogiem systemów z tej kategorii)

7 Zarządzanie tożsamością II. Podział systemów zarządzania tożsamością – Cross domain Dostępne technologie:  Systemy oparte o standardy organizacji Liberty Alliance – koncepcja Federacji (SAML)  Microsoft CardSpace (InfoCards)  OASIS  Yadis / OpenID

8 Zarządzanie tożsamością III. Federacja tożsamości Pojęcia związane z federacją tożsamości  Federacja Circle of Trust (Kółka zaufania)  Elementy kółka: IdP (Identity Provider) – dostawca tożsamości SP (Service Provider) lub Relying Party - usługodawca  Pseudonimy (asercje SAML) Różne identyfikatory tej samej tożsamości u dostawców tożsamości

9 Zarządzanie tożsamością III. Kółka zaufania – federacja tożsamości IdP SP Kalendarz Serwis kadrowy Menadżer projektu Poczta Bank Operator kom. Profil w pracy Profil domowy Kowalski SP Pogoda SP Agregator SP

10 Zarządzanie tożsamością III. Globalne kółko zaufania według Nokia oraz SUN

11 Liberty Alliance Projekt (www.projectliberty.org) III. Cykl federacji Proces rejestracji użytkowników Poza specyfikacją Wymiana informacji (Idp – SP) Federacja SSO Jednokrotne wylogowanie się Zakończenie federacji Rejestracja pseudonimów

12 Zarządzanie tożsamością III. Przebieg procedury łączenia kont, oraz federacji tożsamości w kółku zaufania według Liberty Alliance Internauta (IdP)Serwis SP 1) Użytkownik sygnalizuje chęć federacji tożsamości 2) Internauta loguje się do dostawcy tożsamości uwierzytelnienie IdP zapisuje swoją wizytówkę – ciasteczko stronie Internauta loguje się do serwisu Czy chcesz łączyć to konto w ramach federacji? Serwis wykrywa wizytówkę IdP - ciasteczko uwierzytelnienie Tak Serwis przekierowuje Internautę do IdP Żądanie potwierdzenie statusu uwierzytelnienia uwierzytelnienie IdP generuje asercję SAML potwierdzając ą tożsamość Internauty Przekierowanie do SP Asercja SAML Przetwarzanie otrzymanej asercji. Uzgadnianie pseudonimó w z IdP SOAP Strona serwisu. start pracy

13 Zarządzanie tożsamością III. Łączenie kont w relacjach IdP – SP konto IDP dominik@idp Łączenie kont Alias: mr3tTJ Domain: SP1.com Name: dTvIiR Alias: xyrVdS Domain: SP2.com Name: pfk9uz konto SP1 pickwick@sp1 konto SP2 domino@sp2 Łączenie kont Alias: dTvIiR Domain: IDP.com Name:mr3tTJ Łączenie kont Alias: pfk9uz Domain: SP2.com Name: xyrVdS

14 Zarządzanie tożsamością III. Microsoft CardSpace (InfoCards) Standardowy wygląd interfejsu do wyboru kart reprezentujących tożsamość Możliwość generowania identyfikatorów tożsamości Wsparcie wielu standardów, w szczególności Liberty Alliance  Technologia docelowo ma być obojętna na metody uwierzytelniania preferowane przez różne serwisy

15 Zarządzanie tożsamością III. Microsoft CardSpace (InfoCards) Źródło: http://msdn2.microsoft.com/en-us/library/aa480189.aspx

16 Zarządzanie tożsamością III. Yadis / OpenID Umożliwia SSO,  ale nie gwarantuje innych funkcjonalności (np.. z dystrybucją parametrów tożsamości: preferencji etc.) Logowanie przy pomocy adresu URL będącego identyfikatorem tożsamości Integracja z Firefox’em v.3 i Windows Vista.

17 Zarządzanie tożsamością III. Wady systemów wymagających interakcji IdP przy każdej transakcji uwierzytelnienia wąskie gardło architektury (wydajność) wrażliwość na ataki DoS (blokady dostępu) naruszenie zasad ochrony prywatności  IdP jest świadomy, kto i kiedy korzysta z jakich serwisów

18 Zarządzanie tożsamością IV. Systemy scentralizowane wokół użytkowników Systemy oparte o dodód posiadania – „Proof of possesion” Credentica’s U-Prove

19 Zarządzanie tożsamością IV. Credentica’s U-Prove (Faza incjacji) Użytkownik uzyskuje listę tokenów podpisanych przez IdP, każdy do innego serwisu w ramach federacji  IdP nie zna identyfikatorów w tokenach, które podpisuje Tokeny zawierają ukryty, unikalny identyfikator tożsamości, który nigdy nie zostaje odkryty Tokeny mogą posiadać dodatkowe informacje o tożsamości Tokenami zarządza aplikacja kliencka (np.. Smart Card)

20 Zarządzanie tożsamością IV. Credentica’s U-Prove (Faza incjacji) Źródło: „Secure User Identification Without Privacy Erosion”, Stefan Brands

21 Zarządzanie tożsamością IV. Credentica’s U-Prove (Uwierzytelnienie) Proces inicjacji w serwisie – połączenie tokena z kontem użytkownika  Tokeny to losowe numery (zapobiega to ew. śledzeniu, nie da się ich także łączyć ze sobą – pomiędzy różnymi serwisami) Kolejne logowania  Okazanie tokena  Wygenerowanie dowodu posiadania klucza prywatnego ukrytego w tokenie SSO – poprzez jednokrotne uwierzytelnienie na karcie (aplikacji zarządzającej)

22 Zarządzanie tożsamością IV. Credentica’s U-Prove (Współdzielenie informacji) Źródło: „Secure User Identification Without Privacy Erosion”, Stefan Brands

23 Zarządzanie tożsamością Pytania